How do I add a CSLA Business Rule that depends on a property contained in the parent?

[Prashant3110kk]

I have a scenario where I need to access checkbox value (present in parent) in child which is a list
I need to validate the child object depend on the checkbox value
can someone help me here. any help is appreciated
Thank you

[hurcane]

There are several ways to model this behavior. We favor mirroring the property value in the child class and make the parent class responsible for notifying the children when the value changes (if needed). Usually, the list will include a method for the parent to use, and the list handles iterating the children and updating them.

You can use a managed property in the child class without defining a "regular" property. You would need a method to call SetProperty(), which allows the necessary rules to fire. Another option we use is to define a regular property with a public getter with a friend setter.

[rockfordlhotka]

I like those suggestions.

Also, a rule can have access to context.Target if you enable that feature in the rule's constructor. This is only viable in a sync rule - doing this in an async rule is very dangerous!

If you have the target, that's a reference to the business object containing the rule. And all CSLA domain types have a Parent property that you can use to access the object's parent, which is often a list, so the "real" parent is often the context.Target.Parent.Parent.

These types will all be polymorphic interface types, so you'll need to cast them to use them, but it should get you to the parent.

[Prashant3110kk]

@hurcane Thanks for the suggestion, I'm going with your suggestion as context.Target is somehow not available for me I'm using CSLA 3.8.4.0
I'm trying to set mirrored property in child object but it remains false for new item, do you have a code snippet to set property from parent business class to child business class,

[rockfordlhotka]

You have to enable context.Target in the rule's constructor. By default it isn't provided, because using it can add complexity, so we default to not providing it - the assumption being that if someone does enable it, that they won't do so (for example) in an async rule.