Parent Child Relationships

crgsmrt posted on Tuesday, November 07, 2006

Dear all,

I'm a little new at this so please excuse my ignorance and potential stupid questions. What I'd like to determine is whether I should be creating parent-child-grandchild relationships, or whether I am going about my design approach incorrectly using the CSLA Framework.

I have a BusinessBase class instance called vehicleProgression. This object is a root object and contains many data members and accessors. One of the data members is a strongly typed collection of BuildScheduleItems which is called BuildSchedule; it is inherited from the BusinessListBase class. Before an instance of a BuildScheduleItem can be saved (one of the items contained within the BuildSchedule) it needs to be validated to make sure that it complies with it's rule-set. In order to do so the BuildScheduleItem needs to obtain data from its grand-parent, the vehicleProgression instance.

A little background may help. A vehicleProgression class instance is a facade for existing data from another system - it basically tracks the progress of a vehicle's purchase and re-sale (for a vehicle trader). I.e. a vehicle is bought, sent to a set of locations to have work undertaken on the vehicle, and is eventually sold. The BuildSchedule is a collection of locations to which the vehicle must visit in order to have work undertaken and a BuildScheduleItem is information that specifically relates to the place at which the vehicle is to be worked upon - i.e. Location, estimated arrival date, estimated departure date, etc.

Where was I?...Oh, yes...So, in order for a BuildScheduleItem to validate itself (i.e. estimated arrival date is correct) it needs to communicate with the vehicle progression object to determine when the vehicle was purchased by the dealer - as in this case, a vehicle cannot be worked upon at a specific location until it has been purchased. The purchase date is contained within the vehicleProgression (at root level). Therefore, the BuildScheduleItem needs to be able to communicate with it's grand-parent (as its parent is the BuildSchedule (inheritied from BusinessListBase) collection) to determine whether it's dates are valid.

Now, my approach to this is to the expand the BuildSchedule (which is inherited from the BusinessListBase) so that the BuildScheduleItem can execute code similar to...

_parent <--This gives a reference to the BuildSchedule

.Parent (internal proprerty) <-- This gives reference to the vehicleProgression

.GetPurchaseDate()

So, it would look similar to this:

_parent.Parent.GetPurchaseDate();

However, the BusinessListBase does not contain a variable to hold a reference to the parent. I would imagine that this is by design - so this raises alarm bells in my head. Is this the way that I should be tackling this problem? Or, have I put the cart before the horse once again?

I'd really appreciate any help anyone may offer.

Thank you.

Craig.

RockfordLhotka replied on Tuesday, November 07, 2006

BLB doesn't maintain a parent reference because such a reference isn't required by the framework. But there's no reason why you can't maintain such a reference yourself.

To implement this, just make sure to mark the _parent field as NonSerialized and NotUndoable, or you'll end up with some bad circular reference issues. The challenge with NonSerialized, is that you also need to re-hook the reference during the deserialization process. Specifically, the parent object needs to override OnDeserialized() and reset the parent reference in the child collection.

Due to that requirement, the child collection needs a Friend/internal method that can be called by the parent. You can see the model I used in BusinessBase, and you can follow that basic model in implementing your own parent reference.

RealQuiet replied on Wednesday, November 15, 2006

Is it possible that we could get away with just marking the _parent field NotUndoable and not marking it NonSerialized? I just did a quick test, with a child holding a reference to his parent with the NotUndoable attribute. Everything seemed to stay intact with no errors after serialization/deserialization, so it looks like the serialization and deserialization handles the circular reference ok. Does anyone see any problems doing this?

ajj3085 replied on Wednesday, November 15, 2006

I think it works, but you end up with a much larger byte stream than if you marked it NonSerialized.

RealQuiet replied on Thursday, November 16, 2006

Just to follow up on this, I tested this on my fully populated business object graph. I first serialized the graph marking the references back to the parent as [NonSerialized]. The size of this was 40,631 bytes. Then I serialized it without the parent references marked as [NonSerialized]. The size of this was 40,865 for a difference of 234 bytes or about 1/2% overhead in my case. Seeing that it appears to be very minimal hit, I think this is the route I will take instead of worrying about resetting the references on deserialization. Again, feel free to shoot holes in this approach if you think I'm way off track with this.