title: Implementing NotifyPropertyChanged without magic strings
body: <blockquote>
    <p><strong>Possible Duplicate:</strong><br>
    <a href="https://stackoverflow.com/questions/2711435/typesafe-notifypropertychanged-using-linq-expressions">typesafe NotifyPropertyChanged using linq expressions</a>  </p>
  </blockquote>
  
  
  
  <p>I'm working on a large team application which is suffering from heavy use of magic strings in the form of <code>NotifyPropertyChanged("PropertyName")</code>, - the standard implementation when consulting Microsoft. We're also suffering from a great number of misnamed properties (working with an object model for a computation module that has hundreds of stored calculated properties) - all of which are bound to the UI.</p>
  
  <p>My team experiences many bugs related to property name changes leading to incorrect magic strings and breaking bindings. I wish to solve the problem by implementing property changed notifications without using magic strings. The only solutions I've found for .Net 3.5 involve lambda expressions. (for example: <a href="https://stackoverflow.com/questions/1315621/implementing-inotifypropertychanged-does-a-better-way-exist/1316566#1316566">Implementing INotifyPropertyChanged - does a better way exist?</a>)</p>
  
  <p>My manager is extremely worried about the performance cost of switching from</p>
  
  <pre><code>set { ... OnPropertyChanged("PropertyName"); }
  </code></pre>
  
  <p>to</p>
  
  <pre><code>set {  ... OnPropertyChanged(() =&gt; PropertyName); }
  </code></pre>
  
  <p>where the name is extracted from</p>
  
  <pre><code>protected virtual void OnPropertyChanged&lt;T&gt;(Expression&lt;Func&lt;T&gt;&gt; selectorExpression)
  {
      MemberExpression body = selectorExpression.Body as MemberExpression;
      if (body == null) throw new ArgumentException("The body must be a member expression");
      OnPropertyChanged(body.Member.Name);
  }
  </code></pre>
  
  <p>Consider an application like a spreadsheet where when a parameter changes, approximately a hundred values are recalculated and updated on the UI in real-time. Is making this change so expensive that it will impact the responsiveness of the UI? I can't even justify testing this change right now because it would take about 2 days worth of updating property setters in various projects and classes.</p>