Business Rule in parent object that needs property value from child

[Chicagoan2016]

We have to implement a business rule in parent object that needs properties' values from both parent and one of the child objects. Should we duplicate the child's properties (the ones needed by the business rule) in the parent object?

Regards

[rockfordlhotka]

I would not do that. I'd cast context.Target to the current object's type and then navigate the object graph to find those properties directly.

Remember that all child objects do have a Parent property that references the parent, and of course the parent always has properties that reference the child objects. So you can navigate up and down the graph.

The drawback to this is that the rule becomes tightly coupled with the shape of the object graph, but for "non-trivial" rules this is often unavoidable.

[Chicagoan2016]

@rockfordlhotka thank you, I am going to give it a try and will report back : )

[Chicagoan2016]

@rockfordlhotka It turned out some of the properties of the child object are 'calculated' properties from businessrules in child object. Would these properties be available to the business rule in parent object (that needs those calculated properties from child object)?
I am not clear about the order of the AddBusinessRules() method in parent object vs child(ren) object.

Kind Regards

[rockfordlhotka]

AddBusinessRules just attaches rules to properties, it runs the very first time a type is used, and from that point forward all the rules are executed by the rules engine.

So by the time any rules are running, AddBusinessRules was run long in the past.

If you cast context.Target and/or this.Parent to your type you can access any properties or methods on the instance, because you are interacting with the instance directly.

[michaelcsikos]

We have an extension method which can make life a little bit easier when you need to find a particular ancestor object further up the graph. It keeps stepping up the tree until it finds the object type you're looking for. This may allow your business rules to be a little less tightly coupled to the graph.

    public static class CslaExtensions
    {
        public static T GetAncestorAs<T>(this IParent instance)
            where T : class
        {
            while (instance != null)
            {
                T ancestor = instance as T;

                if (ancestor != null)
                    return ancestor;

                instance = instance.Parent;
            }

            return null;
        }
    }

And you would use it like this:

var widget = aChild.Parent.GetAncestorAs<Widget>();
// or
var widget = Parent.GetAncestorAs<Widget>();
// Interfaces can be helpful, too
var widget = Parent.GetAncestorAs<IWidget>();