Few comments on root/child objects

Bahadir posted on Saturday, September 16, 2006

Hi,

I've read the Expert C# 2005 Business Objects book and enjoyed it. Few comments though.

1) Although I am a total novice, I think that a child and root object should have been made more uniform, i.e. look like each other. This simplifies design.

a) For instance there's an optimisation that a root collects child data in a single database transaction and passes the DataReader to the child. This is an optimisation that reduces clarity. In my opinion this could have been discussed with an inline paragraph, or just mentioned later in an enhancements section. As a novice it increased complication for me.

b) A child doesn't have data access criteria like a root. For instance a ProjectResource object updates the database via an Update(Parent parent) and in the process involved is both a local field, _resourceid and a parent field, parent.Id. Don't you think the local field also need be passed by a criteria object?

I encountered these issues while converting a root to a child. If you disagree I would like to know your opinion.

Thanks,
Bahadir

JoeFallon1 replied on Saturday, September 16, 2006

The first time you read the book you don't really understand the depth of the framework Rocky has created. It really takes stepping through the code in a live example to graspmany of the concepts. Project Tracker is a good place to start. But designing a small app and implememnting your own BOs is a better place. Then you can understand things better. YMMV.

a.) This is not an optimization but a key part of the design which Rocky has spent over a decade evolving. A Root fetches its own data plus its children's data. Grandchildren actullay add complications and there a couple of approved solutions there. Some people populate a dtaaset with relations and then use that to "hydrate" their BOs. I open a 2nd reader and let children get their own children.

b.) The Parent refernece passed to the child is most useful when using Identity values as the PK and you insert the Parent record first. Then you get back the newly created key and need to pass it to the child BO so it uses it when being inserted 2nd. I have not run into cases where I need the parent for anything else. So I created an IParent Interface witha Key Property and pass that when required. Works fine for me.

 

 

Bahadir replied on Sunday, September 17, 2006

Hi,

Thanks, after spending some more time on it I'm convinced passing the data readers are a key part in root/child relationship.

Is there any smaller working code example (preferably a website) than the ProjectTracker? For example, a very basic implementation with one root collection and its children or a similar combination? Once I fully figure out this pattern it should be simpler to build on it.

Thanks,
Bahadir

ajj3085 replied on Monday, September 18, 2006

JoeFallon1:

a.) This is not an optimization but a key part of the design which Rocky has spent over a decade evolving. A Root fetches its own data plus its children's data. Grandchildren actullay add complications and there a couple of approved solutions there. Some people populate a dtaaset with relations and then use that to "hydrate" their BOs. I open a 2nd reader and let children get their own children.

Actually it is an optimzation and not a key part of the design.  There's no Csla reason each individual object can't get its own data, just like the root did.  Its just that you add more database hits and reduce performance.

Indeed, you could argue that you are somewhat breaking encapsulation by allowing the root to get its children's data.  Ideally, the root wouldn't know much at all about its chlidren.