Intra-graph Business Rule

[bashinamwila]

We have BO which has a child object which is an editable child collection which in turn has a number of editable child objects.The child objects need to access some properties in the root editable object to perform some calculation.On data portal requests the Parent object is null,and so we have opted to call the invocation of child object business rules using the ICheckRules interface from the Csla.Core namespace.When the child object is added to the collection or when the collection is fully loaded in the root object.In the Csla 4 Object book the recommendation by @rockfordlhotka is the use of this interface leads to difficult to maintain code.

1. Where is the recommended location to call the child business rules in this instance?
2. One of the child objects needs to access the property of another child object in the collection.The problem we have the child object need to recalculate its values when the property of the other child object changes.How do we achieve this?
3. We also need to keep track of the old values when property changes as the old values are used in the calculation.What is the best way to achieve this?Is the creation of properties such as oldAmount, OldEffectiveDate and loaded with values from the db and then we can compare the oldAmount value with Amount value.This seems to work but results with a BO an extra property for each property is there a better way we can achieve this?

Many Thanks

[rockfordlhotka]

I'll take a first pass at some answers.

1. You probably want to invoke the rules at the bottom of your Create method in the root object, because that is the only point where your code is running on the server, and where you know that the entire object graph has been materialized into memory
2. CSLA provides a pretty comprehensive "child changed" eventing model, and generally you'll handle a child changed event in the parent or grandparent object to trigger running rules below that point in the object graph; I typically try to put this code in the next BusinessBase ancestor rather than in a BusinessListBase; but either way can work
3. This capability exists in CSLA, but isn't part of the standard implementation because it literally doubles the amount of memory consumed by an object graph, and doubles the amount of data transferred over the network via the data portal; which makes sense since you are maintaining the old and current values for each property; basically look at Csla.Core.FieldData - you need to implement your own IFieldData<T> class that is similar to the standard one, but which maintains the old value as well as the current value

[bashinamwila]

Thanks Rocky

[Chicagoan2016]

@rockfordlhotka , Is number 3 the same as @JasonBock implemented a 'couple' years ago?
Thanks

[rockfordlhotka]

I believe so, yes.