Progressive Digressive Marcus Whitworth's tech blog – .NET, C#, Silverlight, WPF, Flex…etc, etc

Dynamic Linq with Expression Trees

I recently came across a project requirement for the client to create custom validation rules for retrieving data from the SQL database. The rules needed be applied against any number of member applications, and can be altered by the client at any point.

From the client perspective, the administration of the rules would look something like the following:

Simple enough concept.  Historically, given such a requirement, you'd likely end up with some fudged SQL string (if querying a database), and/or a whole lot of conditional logic.  The application already uses Linq2SQL, so I didn't want to go backwards by introducing some extensive SQL string generation.

The first Linq based option I came across was the Dynamic Linq Query Library, which essentially enables you to use SQL-like strings as expressions in your conditional clauses.  Nice, but it still smelled a bit like the SQL string concatenation of old.

The second option I looked at was PredicateBuilder.  It's a neat solution for the right problem, but it assumes that you know the properties/columns you're querying against at compile time.

So, I decided to have a play around with Expression Trees, in an effort to dynamically generate my conditional expressions at runtime.  I hadn't really delved much into this area before, so I figured it'd be a good learning experience, even if it didn't end up working out.  To cut to the chase, the method I ended up with for parsing my rules into Lambda Expressions looks like the following:

public static Expression<Func<T, bool>> GetExpression<T>(
	string propertyName, string operatorType, string propertyValue)
{
	var isNegated = operatorType.StartsWith("!");
	if (isNegated)
		operatorType = operatorType.Substring(1);

	var parameter = Expression.Parameter(typeof (T), "type");
	var property = Expression.Property(parameter, propertyName);

	// Cast propertyValue to correct property type
	var td = TypeDescriptor.GetConverter(property.Type);
	var constantValue = Expression.Constant(td.ConvertFromString(propertyValue), property.Type);

	// Check if specified method is an Expression member
	var operatorMethod = typeof(Expression).GetMethod(operatorType, new[] { typeof(MemberExpression), typeof(ConstantExpression) });

	Expression expression;

	if (operatorMethod == null)
	{
		// Execute against type members
		var method = property.Type.GetMethod(operatorType, new[] {property.Type});
		expression = Expression.Call(property, method, constantValue);
	}
	else
	{
		// Execute the passed operator method (e.g. Expression.GreaterThan)
		expression = (Expression) operatorMethod.Invoke(null, new object[] {property, constantValue});
	}

	if (isNegated)
		expression = Expression.Not(expression);

	return Expression.Lambda<Func<T, bool>>(expression, parameter);
}

Which can be executed with a call like the following:

foreach (var rule in rules)
{
	applicants = applicants.Where(
		GetExpression<Applicant>(
			rule.MemberName, // The Applicant property
			rule.Operator, // Equals, Contains, GreaterThan, etc
			rule.Value)
		);
}

The rules are looped over, and Linq does its magic by combining all the separate rules with AND statements in the resulting query.

A few things to note:

• Operators are just the method names to be called, against the Expression type, or any other CLR or custom type.  If you put a ! in front of the operator, it negates the method result (!Contains would read 'Does Not Contain').
• Reflection isn't necessary for building an expression, I just use it here to enable runtime operator implementation, against both the Expression class and potentially any other class.
• If you wanted to combine your rules with OR statements, it could be done easily enough with logic similar to what PredicateBuilder uses.
• There is possibly/probably better ways to do this - if you know one, speak up!

Is this necessarily any better than using the Dynamic Linq library?  A bit - it doesn't really give me any compile-time type safety benefits, but I could potentially handle certain exceptions that I perhaps wouldn't be able to detect using Dynamic Linq, such as casting the value to the correct type.  On top of that, I like it more, it feels more robust, and doesn't require external libraries to work.  If nothing else, it gave me an excuse to get my head around some lower-level Expression Tree stuff :)

var mediaPath = "testClip_h1080p.ism/manifest";
var source = new AdaptiveStreamingSource
{
   ManifestUrl = new Uri(mediaPath, UriKind.RelativeOrAbsolute),
   MediaElement = streamElement // the xaml MediaElement
};
source.StartPlayback();

devenv /resetskippkgs