Using Expressions with Constructors

Every now and then you think "x should be easy" - and it isn't. I had one of those situations this morning. Something I thought would take 5 minutes had me still pondering 30 minutes later. I finally cracked it (with the help of a colleague - thanks Marc!) and I wanted to note down what I did since I'm sure to forget this.

So what's the problem?

In our project we had a very simple validation class. It looked a bit like this:

	public class FieldValidation
	{
	public FieldValidation(string fieldName, string message)
	{
	FieldName = fieldName;
	Message = message;
	}
	public string FieldName { get; set; }
	public string Message { get; set; }
	}

view raw FieldValidationBefore.cs hosted with ❤ by GitHub

I wanted to take this class and extend it to have a constructor which allowed me to specify a Type and subsequently an Expression of that Type that allowed me to specify a property. 10 points if you read the last sentence and understood it without reading it a second time.

Code is a better illustration; take a look below. I wanted to go from #1 to #2:

	//#1 Specify field name up front - how we currently use this
	var oldSchoolValidation = new FieldValidation(
	"WithAProperty", "Message of some kind...");
	//#2 Field name driven directly by property - how we want to use this
	var newSchoolValidation = new FieldValidation<AnObject>(
	x => x.WithAProperty, "Message of some kind...");
	/// <summary>
	/// Example class for demo
	/// </summary>
	public class AnObject
	{
	public bool WithAProperty { get; set; }
	}

view raw HowItIsUsed.cs hosted with ❤ by GitHub

"Why?" I hear you ask. Well we had a swathe of statements in the code which test each property for a problem and would create a FieldValidation with the very same property name if one was found. There's no real problem with that but I'm a man that likes to refactor. Property names change and I didn't want to have to remember to manually go through each FieldValidation keeping these in line. If I was using the actual property name to drive the creation of my FieldValidations then that problem disappears. And I like that.

So what's the solution?

Well it's this:

	public class FieldValidation
	{
	public FieldValidation(string fieldName, string message)
	{
	FieldName = fieldName;
	Message = message;
	}
	public string FieldName { get; set; }
	public string Message { get; set; }
	}
	public class FieldValidation<T> : FieldValidation where T : class
	{
	public FieldValidation(
	Expression<Func<T, object>> expression,
	string message)
	{
	//Will work for reference types
	var body = expression.Body as MemberExpression;
	if (body == null)
	{
	//Will work for value types
	var uBody = (UnaryExpression)expression.Body;
	body = uBody.Operand as MemberExpression;
	}
	if (body == null)
	throw new ArgumentException("Invalid property expression");
	FieldName = body.Member.Name;
	Message = message;
	}
	}

view raw FieldValidationAfter.cs hosted with ❤ by GitHub

As you can see we have taken the original FieldValidation class and added in a generic constructor which instead of taking string fieldName as a first argument it takes Expression<Func<T, object>> expression. LINQ's Expression magic is used to determine the supplied property name which is smashing. If you were wondering, the first MemberExpression code is used for reference types. The UnaryExpression wrapping a MemberExpression code is used for value types. A good explanation of this can be found here.

My colleague directed me to this crucial StackOverflow answer which provided some much needed direction when I was thrashing. And that's it; we're done, home free.