Object Relation Mis-Understanding

kbcb posted on Saturday, February 17, 2007

I'm having a hard time understanding a particular concept in the relation of objects in a CSLA environment. I believe it is probably a simple concept, but one I am just not grasping (I have been working in data normalization-based system for a long time, and the behavior-normalization concept is fairly new, but sensible to me).

This is the way my project is setup:
I have three root objects:
1) Participant - Represents domestic information for a single person; Such as Name, Birth Date, Address, Etc.
2) Group - Represents a "Client" (id, name, effective date, banking information)
3) Account - Represents a "family" of participants that are members of A "Group".

Within the account object, I have a list of "Enrollee" objects, which represent the association of a Participant to an Account. Also, within the account, I need a way to reference the Group that the account is associated with.

This is my question:
I am not sure how to setup the association of an account to a group. I thought, initially, that I should have a literal reference to the Group object, but I ran into some issues with fetching my account object and not being able to load my group object unless I wanted to "fully" load my group object. So, then I thought that "behavior" tells me I need a seperate object (perhaps) called "AccountGroup" that represents only the minimal information I need from the group for the account. That worked out OK, with the exception that I now run into a problem with binding to controls on the form. If I have a screen that shows a combo-box of all my Group objects in the system, how do I databind the selection of the control to my account object when the account object has an "AccountGroup" property, instead of a "Group" property.

Perhaps I am missing something far more fundamental... I am not sure. Any help understanding what the "correct" thing to do is would be greatly appreciated.

Thanks!

JonStonecash replied on Sunday, February 18, 2007

The fuzziness may come from some confusion about what the use cases are.  The use cases drive the behaviors that you need from the objects.  From your description, I am guessing that you have a use case that deals with reviewing/updating an account.  Part of that review is specifying the group to which the account should belong.  I assume that the group id is a column within the Accounts table (with a foreign key linkage to support referential integrity).  I will further assume that each group has a name or title that is human-friendly and should appear in the group dropdown on the review/update account form.  Given all of this, the behavior involved is to pick a group ID (from the list) that is to be stored in the Accounts table row.  To support this behavior, the Account(review/update) object only needs a GroupID property, rather than a reference to some type of Group object. 

If you have additional use cases involving the Account, you might well have different  objects; some of those varients of the Account may  have a need to actually reference a variation of a Group object, rather than just the GroupID.  The way that I try to think about these variations to compare them to the concepts of multiple views of the same underlying reality.  Obviously each view has to share some common elements with all of the other views of the underlying reality, but each view may be quite different.  The differences come about because of the purpose (use case) that each view is designed to serve.

Jon Stonecash
Magenic Technologies