The basic of MVVM is an implementation of the INotifyPropertyChanged interface. All View Models must implement it, and the entire binding mechanism between the views and the view models rely on it. A heavy application may create thousands or even millions of instances of objects that implement this interface. They will usually all derive from a single class that exposes the event and allows to trigger it.

So this post dives a little deeper into the INotifyPropertyChanged implementation. There is nothing ground breaking here, this topic appears in several posts, but it is the starting point of every MVVM framework so I must start here. We’ll discuss several possible implementations and pick one that nest answers our requirements.

What are the requirements?

We will focus on two main issues - Performance, and Code neatness. We are looking for an implementation where properties definitions will require the minimum amount of code. We also want refactoring to be as easy as possible and to avoid planting traps to the programmers that will have to modify the code every once in a while.

The basic implementation – String based

Here is the most basic and common way of implementing the INotifyPropertyChanged interface:


And using this base class looks like this:


Each property requires a backing field in order to store the data itself, and then call the NotifyPropertyChanged method on the setter if the value had in fact changed.

This method is the most efficient one as far as performance is concerned (we will review some other methods, all of which require extra functionality which has a negative impact on performance) but it is very problematic as far as refactoring is concerned. Changing the property type requires changes in two different places (the property and the backing field). While this may be OK the compiler will prevent us from changing only one and forgetting the second one, a change to the property name is far more problematic. You need to change the name of the property, the name of the backing field, and the string passed to the notifier. But this is not the worst scenario. Consider the following implementation of a read only expression property:


Notice that UpperCaseStringVal is a property that only has a getter, it is read only. It is dependent on the value of the property StringVal. So changing the StringVal property yields change to two properties and therefore notifies property changed events on two properties. Now, when we change the name of the read only property, we have to modify the string on all places where it is being called. The only way to avoid mistakes is to use “Search and Replace” every time we do that, because with strings, the compiler is not going to help us, there is no automatic way to refactor that, and we can’t know for sure in how many places in the code we call a notification of the UpperCaseStringVal property.


Evaluated Properties

Notice that we now revealed a new implementation requirement. We want to be able to implement at least two types of properties. In addition to the normal read-write getter-setter property, we want to support properties which are actually expressions calculated from the values of other properties. These properties have no setter, so the change notification has to be invoked on the setter of each property it depends on.


In the next post we will examine a few more implementations and pick the winner that gives us the best refactor-ability combined with a decent performance. Stay tuned 🙂