In MVVM model should the model implement INotifyPropertyChanged interface?
Solution 1:
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
andINotifyCollectionChanged
interfaces. Models classes that represent collections of objects typically derive from theObservableCollection<T>
class, which provides an implementation of theINotifyCollectionChanged
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
, orINotifyDataErrorInfo
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.
Solution 2:
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.
Solution 3:
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
.
Solution 4:
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