In MVVM model should the model implement INotifyPropertyChanged interface?

I have clear idea about View and ViewModel in MVVM pattern. I am planning to implement MVVM pattern in my application. I'm facing an issue regarding the model. I have .xml file which is parsed and the information is displayed in the View.

I need to be notified about the changes in the model for the first time only. From onwards on demand I need to be notified.

So how to implement the model?

Should I implement INotifyPropertyChanged interface in model class also? (I read that model should not implement INotifyPropertyChanged interface, since it is WPF specific)

Implementing INotifyPropertyChanged in Models is totally acceptable -

> Typically, the model implements the facilities that make it easy to > bind to the view. This usually means it supports property and > collection changed notification through the INotifyPropertyChanged and > INotifyCollectionChanged interfaces. Models classes that represent > collections of objects typically derive from the > ObservableCollection<T> class, which provides an implementation of the > INotifyCollectionChanged interface.

Although its up to you to decide whether you want that type of implementation or not, but remember -

> What if your model classes do not implement the required interfaces? > Sometimes you will need to work with model objects that do not > implement the INotifyPropertyChanged, INotifyCollectionChanged, > IDataErrorInfo, or INotifyDataErrorInfo interfaces. In those cases, > the view model may need to wrap the model objects and expose the > required properties to the view. The values for these properties will > be provided directly by the model objects. The view model will > implement the required interfaces for the properties it exposes so > that the view can easily data bind to them.

Taken from - http://msdn.microsoft.com/en-us/library/gg405484(PandP.40).aspx

I have worked in some projects where we haven't implemented INotifyPropertyChanged in our models and due to this we faced a lot of issues; unnecessary duplication of properties was needed in VM and at the same time we had to update the underlying object(with updated values) before passing them to BL/DL.

You will face problems specially if you need to work with collection of your model objects(say in an editable grid or list) or complex models; model objects won't be updated automatically and you will have to manage all that in your VM.

The standard MVVM approach is to implement INotifyPropertyChanged only on the ViewModel. The purpose is to refresh the appropriate bindings on the View when something changes in the ViewModel.

However, this targets changes to the ViewModel by the View. That is to say, when you change the value in a TextBox, the INotifyPropertyChanged implementation on the ViewModel will refresh the related Bindings, so the View updates correctly.

It does not cover changes made to the Model by an external source, like Database changes or another interface. As long as all data modifications are coming from the View, the ViewModel should be aware of all changes and know what to update. For example, if you know that changing variable Foo on your Model will also change the value of Bar on you Model, it would be wise to call both OnPropertyChanged(Foo) and OnPropertyChanged(Bar) in your ViewModel when you change the value of Foo.

The other alternative is to use events between the Model and the ViewModel to refresh those values on the ViewModel that require updating. If, as you say, the notification is required "first time only", then implementing a manual once off refresh on some trigger should also work.

This is a very common problem while working with MVVM, INotifyPropertyChanged is not WPF specific as it is part of System.ComponentModel so no need to add any WPF specific reference in your solution.

If you will implement INofityPropertyChanged in your Model, it can save a lot more codes in ViewModel(Proxy Properties). So, it is acceptable your Model uses INotifyPropertyChanged.

Sometimes it is acceptable to have the model implement the INotifyPropertyChanged interface.

For example if the model has a lot of properties to be visualized and you want to avoid to implement a lot of code (proxy properties) in the viewmodel for exposing such model properties.

Look at http://msdn.microsoft.com/en-us/magazine/ff798279.aspx

I'm not sure about what you mean. In the VM you may have either the INotifyPropertyChanged, or DependencyProperty-es (in this case the VM must derive from DependencyObject). Make no sense having both. Also doesn't make sense having none of them.

In the model, you may do whatever you want. The ability to fire/receive events is good, but not always you can rely on them. Basically the model is depending on the source data and related stuffs, while the viewmodel has the load of interface the model with the presentation layer. Since WPF works upon events, at least the VM must provide some notification mechanism.

This is a classic argument between the "pure" MVVM coders and others.

I tend to go by the books whenever I can because most of the times that makes sense. However, in certain scenarios improvising the code according to the needs reduce a lot of duplicate code.

In your case, you can read the XML to a model class and either make a copy of the model class to the viewmodel, or copy the properties you want from the model to the view model. This way you have control for updating the UI/model. If you follow the first approach you need to have Inotifypropertychanged implemetned in your model class and it is acceptable.

Having said that I would try my level best to follow the second approach because that would give me precise control over all the properties which is displayed/manipulated in the view. Also, I will feel much better that I am not breaking the MVVM pattern.