Relationships - Parent / Child?

MikeB posted on Wednesday, May 13, 2009

I am having a hard time grasping how CSLA .net handles relationships. Of course I know that it uses parent / child terminology to refer to a relationship, but in OO concepts, relationships are defined by use case scenarios "A has B", "A belongs to B", "A is used by B", etc.. In most scenerios, it would seem that A doesn't own B but simply has a reference to B. In the examples I have seen, ProjectTrackers and RolodexEF, the relationships are clearly Parent-Child, Project-Resources and Company-Company contacts for examples.

My Scenerio:

I have a Company object and a CompanyList object. There are several relationships defined in my system where a CompanyList is "referenced". A City object references many Company objects, many CompanyCategory objects reference many Company objects, a Product object references many Company objects, and so on....

The Company objects as described above are by no means child objects of any other.

1) Are they still treated as child objects in the CSLA framework?

2) What about in the case where many objects are "owned" by a parent, but simply referenced by others?

Mike B

 

ajj3085 replied on Wednesday, May 13, 2009

It's hard to answer your questions without knowing your use cases. It would be odd that Company is shared between so many use cases... unless maybe it's just a readonly, informational object.

What is Company's responsiblity? If its just "display data," sharing could make sense. If it allows editing, it sounds like your design is incorrect.

Tom_W replied on Wednesday, May 13, 2009

Hi Mike

I know exactly where you're coming from, this took me a while to get my head round!

There's a lot in your post to discuss, but on first read it sounds like reading Chapter 3 of Rocky's book might be a lot of help to you.  The ProjectTracker sample app design does cover the sort of scenarios you're talking about in implementation of the relationships between Projects, Resources and Assignments.

Equally the whole of Chapter 17 relating to the actual implementation of the design in Chapter 3 would probably be useful.

As you say there is a big difference between owning and referencing an object.  In CSLA terms only an object which is owned is a child - one key distinction of a child being that you don't explicitily save it, you tell the parent to save and it updates the children.

This leads onto another key CSLA concept, which is that a lot of the time you don't really want the full editable object, you want a read only subset of it's data, containing only the data applicable for a certain use case.  This is the puropse the xxxxInfo classes in ProjectTracker (e.g. ProjectInfo and ResourceInfo).  These info classes would typically provide a GetXXXX method to return the actual full editable object (e.g. CompanyInfo would have a method called GetCompany which would return the editable Company object).

In terms of collections, the same 'child' concept applies.  An Order would contain a child OrderLines collection of editable OrderLine child objects (so the OrderLine is child to OrderLines, OrderLines is child to Order, you would only ever call save on the Order).

This is different from say a CompaniesInACity collection where I'm guessing the majority of the time you wouldn't be editing the companies, only returning a list of companies for a city.  In this case I would expect the items in the collection to be read only Info objects.

HTH