{
  "$type": "site.standard.document",
  "canonicalUrl": "https://johnnyreilly.com/posts/using-expressions-with-constructors",
  "description": "This article explains how John used LINQs expression to extend a validation class and automatically change the property name.",
  "path": "/posts/using-expressions-with-constructors",
  "publishedAt": "2013-02-13T00:00:00.000Z",
  "site": "at://did:plc:yy3apqjlms24kso7ahn7lbmb/site.standard.publication/3mova7c4nho2b",
  "tags": [
    "asp.net"
  ],
  "textContent": "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.\n\n\n\nSo what's the problem?\n\nIn our project we had a very simple validation class. It looked a bit like this:\n\nI 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.\n\nCode is a better illustration; take a look below. I wanted to go from #1 to #2:\n\n\"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.\n\nSo what's the solution?\n\nWell it's this:\n\nAs 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.\n\nMy 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.",
  "title": "Using Expressions with Constructors"
}