I was expecting that when specifying multiple InputProperties the rule evaluation would be triggered on a PropertyChanged event of any of them.
Example: Property Sum is evaluated as A + B + C, a rule is added for Sum (primary property) with input properties A, B and C. When A, B or C changes, nothing happens.
The alternative is to write 3 almost identical rules with respective primary properties A, B and C. The other 2 are input properties and Sum is an affected property. That works but seems rather ridiculous.
In a nutshell: I am looking for a AddDependentProperty substitute
There are three things: input properties and affected properties and out properties.
Input properties just indicate that your rule needs that property value, so the rule engine copies the value into a dictionary and provides it to you. There's no expectation that you'll change the value just because you needed to look at it. That might simplify some of how this works, but it would be inefficient in the case where you need several properties to evaluate some other property that you are actually changing.
Affected properties are properties you are saying you'll affect (directly or indirectly). These are like dependent properties.
Out properties are properties you've added to the out dictionary. When your rule completes, the rule engine updates the business object properties with the values in that dictionary. Out properties are automatically added to the affected property list.
I figure I understood the various property sets well.
However, no matter whether you use the input properties to calculate a new value for the primary property or to validate it, the result may possibly be different when one (or more) of those input properties change. So you would expect the rule to be re-executed every time one of those input properties changes. This was easily accomplished in version 3 using AddDependentProperty but now there is no real mechanism for it.
I'd say that version 4 only provides dependency declaration in one direction: from the primary property to the affected properties (including the out properties). Not the other way round. The mechanism (internally) is not that different from version 3 but on declaration there's no option to specify this reverse dependance.
You could of course accomplish this by writing a dummy rule that takes a primary property and an affected property and perform nothing within execute. In the previous example you would use this rule for A, B and C with affected property Sum. That should do the trick but seems silly.
Any pointers for a more elegant solution are welcome.
I see what you are saying. You are right, that's a drawback with the new model.
Believe it or not, I rather like your suggestion of a dummy rule. Though I think I'd put it in CommonRules and call it something like Dependency.
BusinessRules.AddRule(new Csla.Rules.CommonRules.Dependency(PrimaryProperty, DependentProperty));
Of course part of the reason I like this idea, is that the new rule engine really doesn't work like the CSLA 3 engine - there's no separate set of objects maintaining lists of dependent properties or anything. All metadata about rules are maintained in rule objects.
So whether we expose this Dependency rule or hide it behind an API, that's how dependencies are set up - be creating a rule with affected properties.
Copyright (c) Marimer LLC