MVVM: Tips when implementing INotifyPropertyChanged

The Context

Pattern:	Model View ViewModel (MVVM) - I'm not going to delve into the pattern itself, just the implications of some decisions faced during its application in a WPF or SilverLight application. For a better understanding of the MVVM pattern, see this MSDN article by Josh Smith, or this great MSDN article about using MEF along with MVVM, bySandrino Di Mattia
Pattern Applications:	Primarily used in the .NET world for SilverLight, WPF, WP7 applications
At Issue:	Deciding at which layer to implement the INotifyPropertyChanged interface
	At left, a depiction of the MVVM pattern: In a typical WPF or SilverLight implementation the View portion is generally XAML, the ViewModel is C#, and the Model is C#. The View owns the ViewModel instance, and the ViewModel owns the Model instance. In some cases the Model might be re-instantiated multiple times during the life of the View - an example would be when loading, binding, and rendering a new data record from the middle tier at the user's request. In other cases the Model might be loaded once with the View and remain inert after that - an example might be a simple toolbar and the meta data that drives its commands and icons. Using XAML, the View can bind to the ViewModel and the Model (typically through view Properties), depending on the UI requirements.

The Question

A friend of mine wrote recently and asked the following question regarding an implementation of the MVVM pattern: "Is
it generally desirable to implement INotifyPropertyChanged on Model classes,
ViewModel classes, or both? "

The answer is, ironically or frustratingly... both are good.  The appropriate approach for your application depends on the way the Model is managed by the ViewModel. While the "Context" in this table does not address the full complexity of an application's requirements, the table entries attempt to depict typical scenarios and provide guidance when you're making implementation decisions.

Object	Context	Implement?	Comments about IPropertyNotifyChanged
ViewModel	Read-only UI View renders asynchronously loaded data, perhaps even more than once The user does not modify the data.	Yes	If you load your data asynchronously or if the user can load a new set of data (a new file or record) the IPropertyNotifyChanged interface implementation will be beneficial.
ViewModel	Read-only UI View renders synchronously loaded data once The user does not modify the data	No	There is no use to implementing the IPropertyNotifyChanged interface , unless the data for your model is loaded asynchronously - in this case you would benefit from implementing the interface.
Model	Interactive UI View load is synchronous or asynchronous Specific consideration is that Model properties change based on UI actions or background data synching.	Yes	Scenario one: UI updates the model properties during user interaction - the benefit of implementing the IPropertyNotifyChanged interface can be realized in real-time data validation and/or real-time data updates to the middle-tier. Scenario two: The UI needs to be updated due to background data synchronization tasks (either server push or client poll) - the IPropertyNotifyChanged interface implementation allows the UI to keep fresh when new data arrives.
Model	Read-only UI Model properties do not change due to UI interaction or background data synchronization.	No	There may be no benefit to implementing the IPropertyNotifyChanged interface. While some use-cases may differ, generally in this context you don't need to implement the interface.

 

How can you say "both"?

The appropriate application of this INotifyPropertyChanged interface is deterministic, and has to be evaluated in terms of the specific requirements of your application and UI. I hope this helps to provide some useful guidance in your adoption of the MVVM pattern!

Comments

• Anonymous
  June 28, 2011
  Nice article, but your table talks about IPropertyNotifyChanged instead of INotifyPropertyChanged. :-) Regards, Marcel