Hi Rocky,
I just debugged the call to LoadProperty which set the value of an editable child object.
Csla calls SetParent for the newValue, but does not care about resetting the parent reference of the oldValue...
There might be references to the old child somewhere else (UI, etc.), which would still interact with the parent.
I suspect the same is true for SetProperty.
Another thing that comes to my mind is the loading of Inter-Graph references where setting the parent seems wrong.
This relates to Csla 4.8.4 and maybe also Csla 4
What do you think the parent reference should be for an old value? null?
I am aware that calling LoadProperty on an editable child property outside the context of the root object's fetch or update operation is rare.
When following the standard pattern this will never happen. But it is still thinkable e. g. refreshing an editable child with the current data from the DB.
I just did this in the context of a unit of work object. I delegated Save to a command object that provided the UoW object with updated data. In order to achieve this, I had to call LoadProperty on the editable child property...
I would sugest the following logic in BusinessBase:
IEditableBusinessObject oVal = oldValue as IEditableBusinessObject
if (oVal != null && oVal.Parent != null && ReferenceEquals(oVal.Parent,this))
{
oVal.SetParent(null);
}
This will also handle inter-graph references correctly, at least references to list items.
This should be called in
private void LoadPropertyValue<P>(PropertyInfo<P> propertyInfo, P oldValue, P newValue, bool markDirty)
somewhere around the call to RemoveEventHooks(old);
There's a wish list item to make child references of single objects work more like a child in BLB.
If that change occurs (and I would like to do it at some point), the standard behavior when you replace an existing child with a different child, is that the old child would go to a "deleted list" and would be marked for deletion. When the parent is saved, any old child objects would be deleted.
When an item in a BLB is moved to the DeletedList its Parent property is unaffected (the Parent is still the BLB), and from a consistency perspective the same would be true for the child of a single editable object.
What you are suggesting isn't without value - but it directly contradicts the plans I'm describing here for a future change in CSLA.
OK, I see your point there.
What initially bothered me, was a scenario, where an "old child", that has been replaced by LoadProperty or SetProperty, could still interact with its parent through business rules still beeing executed (asynchronously!) on the "old child" and probably raise events in the parent...therefore my objections.
I see this is "pre Child_Changed style", and nobody knows how many of us still have those rules interacting with the parent.
So if resetting the parent reference is not an option, disabling the business rule subsystem on the oldValue child instance would solve my problem.
And now I am on slippery ground, because I haven't checked if that is already implemented / or possible.
Before CSLA 4 there's a property on ValidationRules that will suppress rule checking. Set it to true in your object and it stops running rules.
In CSLA 4 there's a property on BusinessRules that will suppress rule checking - it does the same thing.
In CSLA 4 there's also an ICheckRules interface that allows you to turn off rules for an object from the outside. This is intended for use in ASP.NET MVC apps, but it can be used in other scenarios as well.
I discuss all the ways to suppress rule checking in CSLA 4 in the Using CSLA 4: Creating Business Objects ebook.
Copyright (c) Marimer LLC