Who is responsible?

ajj3085 posted on Friday, July 14, 2006

Hi all,

I'm reworking my PhoneNumbers and Phone objects to be able to 'belong' to any other root object; currently that is just a Contact, but I'm going to be adding PhoneNumbers to Company and Department objects.

In the database, I have  Phone and PersonPhone (and soon CompanyPhone and DepartmentPhone).  Its pretty clear the Phone object maintains the Phone table.  It also doesn't seem like PhoneNumbers should know at all about PersonPhone.

So my question is, is it appropriate to have Contact (and Department and Company) manage the PersonPhone table?  It seems reasonable to me, what does everyone else think?

Note that the changes from the UIs perspective would only be the addition of PhoneNumbers to Department and Company, so I think the BO design is good... just wanted to know what others have done to handle this.

Thanks
Andy

JonM replied on Saturday, July 15, 2006

Andy,

I would recommend just having one table of phone numbers.  I would also create a phoneNumbers child collection of editable child objects that you would reuse on each object you wanted to have phoneNumbers.  The phoneNumber objects simply needs a foreign key to attach them to their parent (the CompanyID, PhoneID, or DepartmentID).  If you are using integers for primary keys you may have to add an extra column to denote which group the number belongs to.  If you are using GUIDs for primary keys then you should be all set.  This is basically what I have done for my own system reguarding phone numbers (or ContactInfo), addresses, and contacts.

ajj3085 replied on Monday, July 17, 2006

Jon,

I thought of this approach and I'm using ints for keys.  The problem with this method is that you lose foreign key constriants, and it makes joins much messier (since i have to hardcode a typeId to join on).

I came up with what I think is a workable solution over the weekend; basically, I'll change my PhoneNumbers class from sealed to abstract.  I'll add two methods, OnItemDeleting and OnItemSaved (with OnItemDeleted and OnItemSaving potentials for addition later) which will fire just before the number is about to be deleted or after its saved.  I can then create subclasses, which will be internal to the assembly only, that provide implementation of those.  In those methods, I'll handling working with the link tables.

Sounds reasonable to me, what about everyone else?

Andy

vargasbo replied on Monday, July 17, 2006

How are you losing FK constraints? I haven't seen this issue before, so I'm curious. I did my phone number the way Jon talked about, so if I'm going to run into issue down the line, I would like to know now :-)

ajj3085 replied on Monday, July 17, 2006

You've denormalized some of the data, so you have a column, OwnerId (int).  The owner could be a Department, Company or Contact.  Since I have seperate Department, Company or Contact tables, I can't now create a foreign key constraint in Sql Server from OwerId to the parent table.

vargasbo replied on Monday, July 17, 2006

If you found something that works for you great! I don't have all the biz requirements in front of me, but I also if I need to know who my parent is, I set that when I load my child collection. Then you don't have to lose who the parent is.

Tom Cooley replied on Monday, July 17, 2006

Andy,


I would consider creating an IPhoneOwner interface:

interface IPhoneOwner
{
    int OwnerId {get;set;}
    string InsertSP {get;set;}
    string UpdateSP {get;set;}
    string DeleteSP {get;set;}
}

This way you can strongly type which root objects can own a phone number and abstract the few pieces that are different for each.

ajj3085 replied on Monday, July 17, 2006

I use a DAL, so I wouldn't be able to work that approach since my BOs talk to 'data aware' objects without really know how its getting the data.  I implemented the idea I came up with over the weekend, and it seems to work well.  In the future when I need to let Departments and Companies have Phone Numbers, all I need to do is create the subclass and implement two short methods.

pelinville replied on Saturday, July 15, 2006