.NET Zone is brought to you in partnership with:

Michael Ceranski is a .NET developer from Buffalo NY. He has been writing code for over 10 years starting with Borland Delphi and later migrating to the .NET stack. Michael enjoys blogging about .NET, MVC and jQuery. When Michael is not consulting he spends his time working on WeBlog, a next generation blogging platform written in ASP.NET MVC 2. Michael is a DZone MVB and is not an employee of DZone and has posted 34 posts at DZone. You can read more from them at their website. View Full User Profile

Implementing INotifyPropertyChanged with Compile Time Checking

03.27.2012
| 4590 views |
  • submit to reddit

Once you start doing WPF MVVM development you will quickly grow tired of implementing the INotifyPropertyChanged interface. So in order to preserve my sanity, I create a base class which implements the INotifyPropertyChanged interface. The first version of my class was defined as:

public class NotifyPropertyChangedBase : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged = delegate { };

    protected void RaisePropertyChanged(string propertyName)
    {
        PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
    }
}

This is about as basic as an implementation of INotifyPropertyChanged can get. To use it, you just implement the class and call RaisePropertyChanged. Here is an example:

public class MyViewModel : NotifyPropertyChangedBase
{
    private string _name;
    public string Name {
      get{ return _name; }
      set{ 
       _name = value;
       RaisePropertyChanged("Name");
      }
    }
}

After using this version of the code for a couple of days I quickly realized that using a lambda to get the property name would be less error prone than using a string. So in version 2 of the code, I added lambda support.

By the way, the ExtractPropertyName method you see below, was copied verbatim from the Prism project. Prism and MVVM Light Toolkit both take care of wrapping the INotifyPropertyChanged interface.  I personally do not use either framework because I feel that they are both too bloated for my purposes. After a bit of contemplation, I ended up building my own MVVM framework, which I have packaged up and placed on my private NuGet server. However, if you are new to .NET or MVVM then I would suggest starting with a framework first. In any case, here is the updated code:

protected void RaisePropertyChanged<T>(Expression<Func<T>> propertyExpression)
{
    var propertyName = ExtractPropertyName(propertyExpression);
    RaisePropertyChanged(propertyName);
}

protected string ExtractPropertyName<T>(Expression<Func<T>> propertyExpression) {
    if (propertyExpression == null) {
        throw new ArgumentNullException("propertyExpression");
    }

    var memberExpression = propertyExpression.Body as MemberExpression;
    if (memberExpression == null) {
        throw new ArgumentException("The expression is not a member access expression.", "propertyExpression");
    }

    var property = memberExpression.Member as PropertyInfo;
    if (property == null) {
        throw new ArgumentException("The member access expression does not access a property.", "propertyExpression");
    }

    if (!property.DeclaringType.IsAssignableFrom(this.GetType())) {
        throw new ArgumentException("The referenced property belongs to a different type.", "propertyExpression");
    }

    var getMethod = property.GetGetMethod(true);
    if (getMethod == null) {
        // this shouldn't happen - the expression would reject the property before reaching this far
        throw new ArgumentException("The referenced property does not have a get method.", "propertyExpression");
    }

    if (getMethod.IsStatic) {
        throw new ArgumentException("The referenced property is a static property.", "propertyExpression");
    }

    return memberExpression.Member.Name;
}        

With the lambda version of RaisePropertyChanged in place, I can now get compile time checking. Compile time checking is great if you have fat fingers or if you do a lot of refactoring. Let’s take a look at our updated ViewModel:

public class MyViewModel : NotifyPropertyChangedBase
{
    private string _name;
    public string Name {
      get{ return _name; }
      set{ 
       _name = value;
       RaisePropertyChanged(() => Name);
      }
    }
}

Now for the icing on the cake! I added overloaded versions of the RaisePropertyChanged methods so I could raise multiple properties using a single method call. This is useful when you have two of more related properties:

protected void RaisePropertyChanged<T>( params [Expression<Func<T>> propertyExpression] propertyExpressions) {
    foreach( var expression in propertyExpressions ) {                
        RaisePropertyChanged(expression);
    }
}

protected virtual void RaisePropertyChanged(params string[] propertyNames) {
    foreach( var property in propertyNames ) {
        RaisePropertyChanged(property);
    }
}

The classic example of two related properties are Country and State. When you change the value of the country drop down, you want the corresponding states or provinces to appear. Here is an example:

public class AddressViewModel : NotifyPropertyChangedBase
{
     private Address Model { get; private set; }
     
     public AddressViewModel( Address model )
     {
         Model = model;
     }

     public int Country
     {
         get { return Model.CountryId; }
         set
         {
             Model.CountryId = value;
             RaisePropertyChanged(() => CountryId, () => States );
         }
     }

     public ObservableCollection<Country> Countries {
         ...
     }

     public ObservableCollection<State> States
     {
         ...
     } 

     public int StateId
     {
         ...
     }
}

To summarize, if you find yourself implementing INotifyPropertyChanged a lot then I would highly recommend moving that functionality into a base class. In addition, using the lambda version of the RaisePropertyChanged event can provide you with compile time checking which is always a great thing to have!

Published at DZone with permission of Michael Ceranski, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)