Guidelines/FAQ for hierchical object model in CSLA (especially parent/child events)?

Guidelines/FAQ for hierchical object model in CSLA (especially parent/child events)?

Old forum URL: forums.lhotka.net/forums/t/5036.aspx


rsbaker0 posted on Monday, June 30, 2008

I've been in the middle of porting an existing legacy C++ application to CSLA (currently 3.0), but am not finding the guidance in the book with regard to how to handle CSLA-ish concepts as they affect parent/child object relationships.

For example, what child events (if any) does/can/should the parent monitor with respect to child objects and vice versa?

Also, I found myself wanting to have methods on a child object that depended on a parent property. All well and good, except that the parent was a BusinessListBase derived class, and these don't implement PropertyHasChanged(), etc. OK, so you just wrap the BLB in it's own parent BO. Oops, now the child object is now a grandchild and would have to retrieve the property from it's grandparent. My initial reaction to this is Ugh! - why would I need to add an additional object level just to accommodate some CSLA-specific implementation issue.

Are there some blogs or examples of advanced CLSA object models someone could point me to, or should I just ask my specific design questions here as I run into them so we can discuss?

 

SonOfPirate replied on Monday, June 30, 2008

One of the issues I've found typical for developers that are new to CSLA (myself included once upon a time) is the fact that your business object's Parent property is referring to the list that contains the object.  This presents a problem when you want to communicate up the object model.

The first question you have to ask yourself if it really makes sense for a child object to be calling into its parent.  Most likely, you are trying to notify the parent of something that has happened in the child.  This is most easily and effectively accomplished by exposing events in the child object and wiring up handlers in the parent.  The easiest way to do this is to echo the event from its "parent" collection.

A good example of this can be found with the existing PropertyChanged event on a BO and ListChanged event on a list.  Business lists are coded to wire handlers for a contained object's PropertyChanged event which it converts to its own ListChanged event with the ListChangedType set to ItemChanged.

I've often followed the same pattern when bubbling events up an object model.

On the other hand, there are times when you want to reach up the object model.  A good example is the Path property in a tree structure which calls up the object model until it reaches the root then appends its value to the what is returned from the parent.  Because of the Parent issue in CSLA, this can seem problematic but it's really not.

The key is to have a reference from the list that contains your child objects to the parent object.  This is best accomplished by passing a reference to the parent object when the collection/list is instantiated.  For example,

_nodes = new NodeCollection(this);

Once the collection/list has a reference to the parent object, it is easy for the collection to set a reference to the same object when children are added.  Then you can use code similar to:

path = (Parent as NodeCollection).Path + Text;

With both of these techniques, you can have an object model as deep as you need to with events bubbling from bottom to top and methods or properties crawling up the object graph to the top.

Not sure if that completely answers your question, but I hope it helps.

 

rsbaker0 replied on Tuesday, July 01, 2008

SonOfPirate:

The first question you have to ask yourself if it really makes sense for a child object to be calling into its parent. 

Well, I'm not sure, but one question I have is whether a validation rule in a child object might depend on the state of another child in the same list.

For example, say you are trying to avoid duplication (e.g. the same item isn't allowed in the list twice), or in a related way, say with prescription drugs, two different drugs can't be in a formulary because of drug dependencies.

If I allow the user to pick a medication via a drop-down (or enter directly), the validation in this case would need to inspect other medications in the list.

Yes, I can conceive of ways to reign in access to child properties and creation to avoid this a different way, but then sometimes I'm doing "validation" using rules and sometimes by creative design.

Copyright (c) Marimer LLC