I've been using .Net languages for 4 years. I develop 3 tier and 5 tier applications using WCF, ASP.NET for web applications, and C# for windows applications. Every time I start a project, business rules and validations are a concern.
Where should I place custom validation rules (button-click events, page load, or in setters/getters within my classes)?
If a project is large and there is just a field that instead of 5 characters should be 7 characters - Why should I rebuild the whole project (or business classes project)?
I think if I had a file that had my custom rules, then when a change is needed I could simply place a new rule in it. I have read some articles on the internet that offer an XML based file for this purpose, but this seems problematic because:
My Question:
Is there a design pattern or anything else using .NET methods (Reflection, Expression Trees, Lambda Expressions, Dynamics, Runtime Creation of DLLs, etc.) to have dynamic validation using custom rules?
Edit 1)
What about Attributes? Can we use them with Reflection to Custom validations? Can we validate a property according another property(form example P1 should be P2+1) with this approach?
The best way to denote the business rules is in an xml. To take full advantage of this notation, you should start with defining the structure of the rule engine's data model i.e. answer these questions.
Once this is done, create a dummy rules xml and then derive an xml schema based on this xml. The xsd.exe tool can aid you in creating the schema. It is easier to create the schema if you can use tools like Altova XmlSpy.
As for answers to your specific questions,
- We can't using Intellisense and if we have error in XML file it is very hard to find it.
Once you have the schema in place, Visual Studio provides ample support in creating the xml (including intellisense and validation).
- We should write a custom xml parsers
Not required, the XmlSerializer Class provides logic for serialization/deserialization i.e. to convert the rules xml into the rules data model and vice versa.
- Because this method needs numerous casting ,it's very slow
Well, this is a partly valid point when compared to hard coded rules (rules that are embedded into your assembly as classes), but the flexibility of this approach far outweighs any performance demerits. You do not need to rebuild the solution in case there a change in the rules. In most cases, the performance impact is minimal.
Unless you have a strict performance criteria, the xml approach is the preferred way to implement the rules engine. Remember that the more loosely coupled your architecture is, the higher is the flexibility at runtime but there is negative impact on performance.
Sample rule
<RulesEngine>
<Rules>
<Rule Id="Rule1">
<Function>
<Equals>
<Property name="Property1" classId="MyClassId"/>
<Sum>
<Property name="Property2" classId="MyClassId"/>
<Constant type="UInt16" value="1"/>
</Sum>
</Equals>
</Function>
</Rule>
</Rules>
<Classes>
<Class name="MyNamespace.MyClass" Id="MyClassId">
<Property name="Property1" type="UInt16"/>
<Property name="Property2" type="UInt16"/>
</Class>
</Classes>
</RulesEngine>
The rules engine needs to interpret this rule and deduce the meaning accordingly.