Observing Objects for Changes

When waiting for changes in the MVVM pattern, there are many ways to implement the INotifyPropertyChanged interface on your own objects. For example, each of the next approaches has benefits and drawbacks:

1. Manually implement the interface. This can be good for small projects, because you will have no dependencies on other libraries. On the other hand, implementing the interface each time manually is error prone.
2. Use automation to generate the interface implementation. This could eliminate the possibility of not implementing something correctly. A drawback for this approach is that software developers with fewer experience might not be aware that they are not seeing the whole picture in the code. A good engine for this approach is the Fody project and its PropertyChanged plugin.
3. Somewhere between the two, there is a third approach. Implement the functionality it a common base class and derive the objects you want to track from that base class. Benefits of this approach includes that the errors can be easily avoided, but one of the drawbacks is that you will need to derive from a given base class. Given the fact that the .NET system does not allow multiple base classes, in certain scenarios this can be a deal breaker.

I have implemented such a base class in my ObservableObjects library, which can be also installed from NuGet package. In this article, I’m going to walk you through two interesting implementation tricks from it.

Suspending the property change events – And making sure they are restored

Sometimes, you want to change something on objects implementing the INotifyPropertyChanged interface and you don’t want to fire the PropertyChanged event. On such scenario could be that you are in the middle of updating the object and you will change different properties. You want to keep consistency and only fire the change events when you are done with all the properties.

The approach that I took here is that the ObservableObject gives back a lock-like object while detaching the given change event handler. When the lock-like object is disposed it reattaches the event handler to the object. This trick allows us to use it with a using block with the following syntax:

Automatically compiling in caller function name

The second interesting thing is that – and probably this is not new for experienced programmers – you can automatically fill in property names. By defining a parameter on a method with property type of string, default value of null and [CallerMemberName] attribute, the compiler will replace that with the calling method’s name. Using this with the Set method of the ObservableObject allows for easy implementation of the property like the following:

You can connect with me on LinkedIn, Twitter or you can register on the blog. Share if you found this article useful or know somebody who would benefit from reading it.

By subscribing to the email list, you will be notified about new posts.

Name

Email*