How Do I Model Containment?

eslater posted on Friday, May 11, 2007

I have an object (Account) which I want to add a contained object to (ElectronicData).  I am not sure how to accomplish this.  Specifically, I have the following questions:
1 - What type of object would ElectronicData be? (ER or EC)
2 - How would ElectronicData notify Account that it has changed so that Account could initiate a save?

Here is how I am currently attempting to do this:
1 - In the DB I have a ElectronicDataID as a FK to the ElectronicData table.
2 - In the Account class I declare Private mData As ElectronicData = ElectronicData.Create and also have a ReadOnly property to return mData
3 - In DataPortal Fetch I check if the the ElectronicDataID has a value and if so load mData
4 - In Insert/Update not sure how to handle it here.

Am I handling this correctly?  I have a feeling there is a better way to do this but I am not sure what it is.  Any help would be appreciated.

Thanks,
Elliot

eslater replied on Monday, May 14, 2007

Am I doing something unusual here?  There must be others that are using aggregation to add functionality to existing objects?  I am pretty stuck here and am thinking about just going to inheritance but so much of what I have read suggests using containment over inheritance.  If there are others out there that have done this it would be great to hear from you.

Thanks for any help.

RockfordLhotka replied on Monday, May 14, 2007

I'm afraid your problem description doesn't provide enough information - at least for me to help. You haven't specified the use case within which these objects reside, so I can't infer the business domain relationship between these objects, and so can't say what implementation would be best. I'm sure others are in the same situation.

Can ElectronicData exist independantly? Can an Account exist without ElectronicData?

If the answers are yes, then ElectronicData is a root. If the answers are no, then it is a child. yes/no or no/yes then you need two objects, one root and one child (or use the switchable concept - but I recommend against that). If the answers are maybe/sometimes then you need to narrow the focus of your use case so you can get yes or no answers.

eslater replied on Tuesday, May 15, 2007

Account can exist without ElectronicData.  ElectronicData when it exists will be within an account...never independant.  I have a windows form that has all of the Account fields as well as the ElectronicData fields.  If the user enters or changes any data in the ElectronicData fields I need to save this to the database.

Hopefully that clarifies the use case.

So,  I am unsure why I would need both a root and child (or switchable) instead of just a child.  Also, how would I code the DataPortal_Update?    Do I simply have code in Update that checks if the object is savable and if it is save? (If obj.IsSavable then obj.Save)

Thanks for you help Rocky!

RockfordLhotka replied on Tuesday, May 15, 2007

If ElectronicData can't exist outside an Account, then it is very clearly a child of Account. That's the definition of being a child.

Assuming you can retrieve and save an Account independantly, then it is a root, because that's the definition of a root.

So inside the DataPortal_Update/Insert/Delete of Account, you need to call a Friend/internal Update/Insert/Delete method on the child ElectronicData object - just like a collection would do for its child objects.