A client had got a requirement from their customer that specified a rule definition engine that should validate input for a data entry appliation. The specification was completely general and allowed for any arbitrary rule to be processed on any of the current and historic structured data, including intermediate results, mathematical, logical operators and statistical functions. The rules should be maintained by a server administrator. After reading this requirement most developers instantly get the shivers after quickly thinking DSL, parsers, interpreter pattern and lexical analysis. Due to abstractness this is indeed a mammoth requirement. The solution is obviously some kind of DSL that enables an IT pro (rule out XML-based DSLs) to describe a validation rule as a functional expression containing context dependent data properties and common operators. The expression resolves to a boolean value determining if the data passed validation. Expression. Expression tree. LINQ expression trees match the above requirements, are build and evaluated runtime and a technology familiar to many developers. Feeding an expression tree with a domain model of the data will enable writing expressions like:
Orders.Count >= Employees.Count * 20 One thing is missing though. Expression trees are constructed as an object model, not a literal query. The parser that converts a string to an expression tree is included in Microsoft's VS2008 samples. See also ScottGu's walkthrough.
var expr = DynamicExpression.ParseLambda