Compounded Config File Usage Scenario Possible in

Topics: Developer Forum, User Forum
Sep 25, 2007 at 8:04 AM
Edited Sep 25, 2007 at 8:14 AM
To the more experienced .net Validation users:

I have a scenario that requires my business objects by validated dynamically by customer configuration. I'd like to either pass in different XML or programmatically change the validation rules. My concern is... it looks like everything is running through the TypeCache and rules may not be updated as expected. I'm building an project, and there can be multple users accessing the same types, but different instances of the same business types will require different validation rules. Is it possible to solve this kind of scenario?

For instance, given a business object defined as :

class Customer
public Email as string
end class

Assuming this is a product built to cater to multiple businesses:
Business A may want to require that Email be a required field.
Business B may want Email to be optional.

How would I go about setting this up?

Any help would be greatly appreciated.

One solution I was thinking of doing to use the framework with minimal modifications was simply getting rid of the "caching" functionality on the TypeCache. Of course, this would be like a hack -- a Caching class that does no caching. I'm sure this may cause some performance penalty in doing so... I'm hoping there's a cleaner route so I wouldn't have to deal with any hacking.

Sep 25, 2007 at 1:31 PM
The API supports a concept called “ruleSet”.
This allows you to configure different sets of rules for different scenarios.
Have a look at RuleSetForm in the quick start windows application.
Sep 29, 2007 at 8:24 AM
Thanks for the insight Simon... but here's another problem:

Ok, so using rulesets, I came across a scenario where I have 100 rules for a general "ruleset". However, 1 of the 500 business wants just 1 of the 100 rules removed. Would it be wiser to simply create a totally separate ruleset for the business with the exception (I'm thinking this would cost a lot in memory) ? Or is there a way to conditionally disable rules? I'm thinking I could use custom rules, but that would require a re-compile of the project so I'd lose the benefits of runtime configuration.


SimonCropp wrote:
The API supports a concept called “ruleSet”.
This allows you to configure different sets of rules for different scenarios.
Have a look at RuleSetForm in the quick start windows application.

Sep 29, 2007 at 12:00 PM
Edited Sep 29, 2007 at 12:00 PM
These are some very interesting questions and there are a number of factors

For starters, yes you can conditionally enable and disable rules. You can do this through adding and removing rules from the cache programmatically.

However i would recommend against doing this. The whole framework is optimised for the speed of validation rather than the speed of initialization. The reason for this is that initialisation should only happen once where validation of objects can occur in very tight loops. I would only use dynamic rule switching if I know that validation occurs infrequently and memory is extremely limited

So I would lean towards having multiple sets of rules for even if this means duplicating most of the rules. Perhaps one set of common rules for most clients and a few customized ones for the few who differ. I think you will find that the memory required for setting up rules is insignificant when compared to memory used by the application of a whole. The framework makes heavy use of RuntimeTypeHandles and RuntimeMethodHandles. These use much less memory than Type and MethodInfo as they are effectively pointers to the type and method rather than the reflective information.

You could also do a certain level of tweaking using the “context” feature. When doing validation you can specify an object that is passed to all rules during validation. For your one business who wants the rule removed you could make that rule a CustomRule. During validation you could pass through information about the client in the context. Your CustomRule could check this context and not do any validation of it is that specific client.
Sep 29, 2007 at 6:16 PM
That makes sense. I'll probably end up factoring out all the common ones and create custom rules for the exception cases. I can see how disabling types by adding/removing cache entries could have a negative performance with all the locking and initialization that would go on.

Thanks for the help! :)