Dynamic validation using custom rules

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.

1. What are the rules?
2. Can the rules be categorized?
3. Do the rules contain common properties (attributes) like allowed values, format, etc.?

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.

Take a look at FluentValidation. It uses expressions and you can create conditional validations (e.g. validate these properties if that one meets some criteria). FV is perhaps not as dynamic out of the box, but you gain Intellisense, expressiveness, and type-safety. It's generic nature means it runs reasonably fast. You can inject some of the runtime dynamics by passing in validation delegates or custom validators that can do just about whatever you can think of.

It does mean you'd have to recompile, but you could put the validators in a separate assembly. And it does make sense for the validator not to be on/in the class, because you often find that validation is performed in context. For example, a car might be valid if it has all its wheels. But, if you're trying to drive it and it has no gas battery, then it's "invalid" for driving. That said I'd locate the rules "close" to what they are validating as they are part of your domain.

If you need a rule for a property that depends on one or more properties (including itself) and a custom message if the rule's criteria isn't met, you can do this to. Consider this:

RuleFor(x => x.P1)
    .Must(x => x.P1 > x.P2)
    .Message("P1 must be one more than P2. P1 was {0}; P2 was {1}", x=>x.P1, x=>x.P2);

gives a simple comparison, but you could make something much more complex.