Few Suggestions

Topics: Developer Forum
Mar 13, 2008 at 3:34 PM
Edited Mar 13, 2008 at 3:38 PM
I have few suggestions and hope to see them or even help to Implement them:
  1. I suggest Splitting the framework dll into smaller ones like "ValidationFramework.dll" "XMLConfigurationService" , "ValidationFramework.ASP.Adapter" , "ValidationFramework.SWF.Adapter" , "ValidationFramework.WPF.Adapter" or such.
  2. Renaming current "ConfigurationService" which is mainly for XML to something like "XMLConfigurationLoaderService" and making it's based on one interface,So others (like me ) can implement new ConfigurationLoaderService like "DBConfigurationLoaderService" which for example load the configration for a database.
  3. Rather than having 2 classes for each Validator like "RequiredStringRule , RequiredStringRuleAttribute" why shouldn't be only one "ValidatorAttribute" class and it have one or more constructor parameter like: [ValidatorAttribute(new RequiredStringRule() )] string Name { get;set;}
  4. Rather than having one Class of "IRuleConfigReader" for each "Rule" I suggest having one IRuleConfigReader that use reflection to set rule properties then rule itself validate wither current properties combination are valid or not.
  5. From above we will be able to "XAMLConfigurationLoaderService" which load the Configuration from XAML syntax based files and this will save us from writing IRuleConfigReader for each Rule .
  6. And for Rule class one suggestion and easy one (and most important one to me for now at least :) ) adding few properties to Rule Class like :
    1. Severity : something like Level in log4net.
    2. HelpID : string is enough.
    3. KeyValue Attributes collection : so we can attach any custom values .
    4. RuleType : enum { UIRule , BussinessRule } or { ClientSideRule , ServerSideRule } or { UIRule , DomainRule } - BussinessRule / ServerSideRule / DomainRule is a role will require to check App Domain objects to do it's work (like checking the new username is exited or not).
  7. Finally ability to validate against one Ruleset for one RuleType.

Thanks for all of the .net Validation Framework development team for their great work.

Coordinator
Mar 14, 2008 at 12:49 AM
1. Splitting into multiple assemblies.
I agree in principle but let me play the devil’s advocate on this one.
What reasons do you have for splitting the assembly? I realize this would give a separation of concerns, but apart from this, what other benefit does it give?
The memory saving, through not needing to reference certain assemblies would be negligible. The total assembly size is currently 126KB.
It would create more complexity for consumers. They need to work out which assemblies to reference and deploy multiple assemblies.

2. Creating a IConfigurationLoaderService.
This is an interesting one. If you want to have a go at this I think it can be worked into the framework. Remember this would be a breaking change so try to make it an easy upgrade path for existing users.

3. Single Attribute that takes a rule as a constructor
Unfortunately this is not possible. If you try to pass a Rule into an attribute constructor you will get the following error. “An attribute argument must be a constant expression, typeof expression or array creation expression of an attribute parameter type”.

4. A single ConfigReader
This would work for simpler scenarios but I am not sure about the more advanced ones.
Have a look at RequiredStringRuleConfigReader.cs.
Also have you considered the performance hit of using reflection?
Definitely worth some research.

5. XAML
Good idea

6. Extra Properties
Severity: I considered this on several occasions but never got around to implementing it. What list of severities do you propose?
HelpID: Good idea
KeyValue collection: I understand the need for extra information attached to a rule. Should this be an object, a HashTable or a Dictionary<string, object>?
RuleType: Rather than hard coding a custom enum perhaps it would be better to add this property as a string or an object??

7. Ruleset for one RuleType
This should be easy to do.