Invalidate or Refresh Validation Rules

rlvandaveer posted on Tuesday, October 02, 2007

I have run into an issue on a current project related to validation rules and how the ValidationRules class checks them.

I have several business objects that receive different per instance rules based upon the business scenario they are operating under. (It actually took me a little while to figure out that there were per type and per instance rules. I don't think the Expert C# 2005 Business Objects book really explains this very well.) These instance rules are added in response to some event in the system or user input. For example, say we have a user who is copying a fee. For validation sake, we don't want the new fee's values falling outside of an acceptable range relative to the fee being copied, (e.g. a new effective date set earlier than the copied fee's effective date.) In this case, we add a few per instance rules to the new fee to check the date. However, I have noticed that the ValidationRulesManager has already built its list of RulesToCheck. I can find no mechanism for invalidating or refreshing the list of rules. I would think that using ValidationRules.AddInstanceRule() or ValidationRules.AddRule() would automatically invalidate the list for me, but it does not. I've noticed that for per type rules the list does seem to get refreshed from time to time, but I haven't discovered what the trigger for that is.

Is this a bug? Is there a member I am missing or some technique I should be using? I can solve this by forcing the ValidationRules.RulesToCheck property to always rebuild its list but I would like to solve this without modifying CSLA in any way.

Any thoughts would be appreciated. Thank you.

JoeFallon1 replied on Tuesday, October 02, 2007

To my knowledge the list of Rules is built once and then stored in memory. You are not supposed to modify it, or re-build it. Per Type rules do not get refreshed from time to time. They get built once - when the Type is first constructed and then live until the AppDomain is torn down. I guess if your AppDomain is recycled you could say they get "refreshed".

I think you are supposed to build rules with more logic in them to handle your odd cases. These rules get loaded once and then depending on the state of the object return True or False. For example, you might have a rule which always returns True unless some condition exists like: IsMakingACopy. In that case you branch and run the rule to enforce your Copy rules.

So the idea is that rule is always loaded and just works differently for the cases where you need them to.

I do this a lot for IsNew = True objects. New objects have different rule paths than existing ones.

Joe

rlvandaveer replied on Tuesday, October 02, 2007

Thanks for responding Joe. I say that the per type rules get "refreshed" because I have seen instances where a rule that was added to an object at run time caused other instances of the same class to get broken rules based on the newly added type rule with no recycling of the AppDomain.

I don't understand the idea behind loading rules every time, regardless of how an object is being used. It seems to me that this can lead to unnecessary or maybe even incompatible rules and most probably will lead to unnecessarily complex rules. I might ask what the purpose is behind per instance rules if they are loaded and shared among all instances?