Dynamic validation using custom rules

Question

I have been using .Net languages ​​for 4 years. I am developing 3-tier and 5-tier applications using WCF, ASP.NET for web applications and C # for Windows applications. Every time I run a project, business rules and checks are a problem.

Where should I post custom validation rules (button click events, page loading, or to setters / recipients in my classes)?

If the project is large and there is only a field in which instead of 5 characters there should be 7 characters - why should I rebuild the entire project (or the business class project)?

I think if I had a file that had my own rules, then when a change is needed, I could just put a new rule in it. I have read some articles on the Internet that offer an XML file for this purpose, but this seems problematic because:

• Unable to find Intellisense and errors in XML file
• We have to write our own XML parsers
• Since this method requires a lot of debris, it is very slow

My question is:

Is there a design pattern or something else using .NET methods (Reflection, Expression Trees, Lambda Expressions, Dynamics, Runtime Creation DLL, etc.) for dynamic validation using custom rules?

---

Change 1)

What about attributes? Can we use them with Reflection to Custom validations? Can we check the property for another property (an example of the form P1 should be P2 + 1) with this approach?

Answer 1

The best way to identify business rules is with xml. To take full advantage of this notation, you must start by defining the structure of the data model with the rule engine, that is, answer these questions.

• What are the rules?
• Can the rules be classified?
• Do the rules contain common properties (attributes), such as valid values, format, etc.?

Once this is done, create dummy xml rules, and then output the xml schema based on that xml. The xsd.exe tool will help you in creating the schema. It's easier to create a schema if you can use tools like Altova XmlSpy .

Regarding the answers to your specific questions,

• We cannot use Intellisense, and if we have an error in the XML file, it is very difficult to find.

When you have a schema in place, Visual Studio provides extensive support for creating xml (including intellisense and validation).

• We have to write our own XML parsers

Not required XmlSerializer Class provides serialization / deserialization logic, i.e. convert xml rules to rule data model and vice versa.

• Because this method requires a lot of castings, it is very slow

Well, this is partly a valid point compared to hard-coded rules (rules that are built into your assembly as classes), but the flexibility of this approach far exceeds any performance flaws. You do not need to rebuild the decision in case of a change in the rules. In most cases, the impact of performance is minimal.

Unless you have strict performance criteria, the xml approach is the preferred way to implement the rule engine. Remember that the more loosely coupled your architecture, the greater the flexibility at runtime, but there is a negative impact on performance.

Rule example

<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 rule engine should interpret this rule and output the value accordingly.

Answer 2

Take a look at FluentValidation . It uses expressions, and you can create conditional checks (for example, check these properties if it meets some criteria). FV may not be as dynamic out of the box, but you get Intellisense, expressiveness and type safety. This universal nature means that it works fast enough. You can add some runtime dynamics by passing delegates checks or custom validators that can do whatever you can imagine.

This means that you have to recompile, but you can put the validators in a separate assembly. And it is important that the validator is not / included in the class, because you often find that validation is performed in context. For example, a car may be valid if it has all its wheels. But, if you try to drive it, and it has no gas, then it is "invalid" for driving. However, I would find the rules “close” to what they check, since they are part of your domain.