Request/Suggestion: Enhance validation RuleArgs so rule method knows "why" it was called

rsbaker0 posted on Thursday, September 24, 2009

In working with CSLA for a couple of years now, I've found that validation rules can be useful, if carefully coded, for doing transformation on the object data rather than just enforcing rules or displaying error indicators to the user.

The problem is that a rule can be called for at least 3 reasons that I know of:

(1) ValidationRules.CheckRules() was explicitly invoked

(2) The property associated with the rule changed

(3) A dependent property as changed.

If there were an additional property in RuleArgs - say an enum that indicated the invocation cause and was internal to CSLA, set before invoking the rule -- this could greatly simply the coding of transformational rules (and perhaps other rules, for example, those that intend to block changes to an object after it has been locked, etc.). I'd think this could possibly be done as a non-breaking change because existing rule implementations wouldn't care about a new property in RuleArgs.

With the current implementation, the only way I know of for a rule method to be reasonably certain it is being called because the associated property actually changed is to cache the previous property value somehow and compare in the rule method, which increases the weight of the object for each such rule.

Yes, you can accomplish this otherwise by overrides on OnPropertyChanged() or hooking the PropertyChanged event, but rules are already plugged into this mechanism and the determination of which property has changed has already been done. PropertyChanged gets called all the time for unrelated properties which requires a string comparison to test for the changed property, which is also a maintenance issue. Events also have to be hooked and unhooked (and rehooked after saving).  Using rules instead would certainly be convenient and wouldn't seem to add as much cost/complexity.

Thanks!

ajj3085 replied on Thursday, September 24, 2009

I think it'd be useful to have a TransformationRules, which only ONLY be ever called in response to a SetProperty.

I've had problems where calling CheckRules, or having dependant properties actually alters the property because of a transformation rule... and the only way to work around it is to code flags in to avoid the situation.

For example, I have coded business objects for dealing with user accounts. The Password property accepts a string value, and I had a rule that generated a secure salt value then hashed the string.

I spent alot of time trying to figure out why the string wasn't what I expected when dealing with an existing user.. I know I should have realized ealier, but it just didn't click initially.

I think this is why Wpf DependencyProperties have seperate methods for Validation and PropertyChanged... to avoid situtations like this.

Tom_W replied on Thursday, September 24, 2009

This would be useful from a code gen point of view as well.  We do quite a lot of OnPropertyChanged handling because we don't want to add code to the generated property setters (and because there is no such thing as partial property overrides). 

It would be neater to do this in validation rules, and neater still to be able to choose in what scenario the code is actually run.

I think I recall a post Rocky wrote about regretting the use of the name 'Validation Rules' as they have a wider possible usage than just for validation, but I can't find it now.