In MVVM should the ViewModel or Model implement IN

Question

Most MVVM examples I have worked through have had the Model implement INotifyPropertyChanged, but in Josh Smith's CommandSink example the ViewModel implements INotifyPropertyChanged.

I'm still cognitively putting together the MVVM concepts, so I don't know if:

• you have to put the INotifyPropertyChanged in the ViewModel to get CommandSink to work
• this is just an aberration of the norm and it doesn't really matter
• you should always have the Model implement INotifyPropertyChanged and this is just a mistake which would be corrected if this were developed from a code example to an application

What have been others' experiences on MVVM projects you have worked on?

Answer 1

I agree with Paulo's answer, implementing INotifyPropertyChanged in Models is totally acceptable and is even suggested by Microsoft -

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.

---

Originally answered on another similar question, adding here as it contains imp. details missing from this thread -

https://stackoverflow.com/a/6923833/45382

Answer 2

In M-V-VM the ViewModel always (Model not always) implements INotifyPropertyChanged

Check out the M-V-VM Project Template/Toolkit from http://blogs.msdn.com/llobo/archive/2009/05/01/download-m-v-vm-project-template-toolkit.aspx. It uses the DelegateCommand for commanding and it should be a great starting template for you M-V-VM projects.

Answer 3

I thing the answer is quite clear if you wish to adhere to the MV-VM.

see: http://msdn.microsoft.com/en-us/library/gg405484(v=PandP.40).aspx

In the MVVM pattern, the view encapsulates the UI and any UI logic, the view model encapsulates presentation logic and state, and the model encapsulates business logic and data.

"The view interacts with the view model through data binding, commands, and change notification events. The view model queries, observes, and coordinates updates to the model, converting, validating, and aggregating data as necessary for display in the view. "

Answer 4

It depends on how you've implemented your model. My company uses business objects similar to Lhotka's CSLA objects and make extensive use of INotifyPropertyChanged throughout the business model.

Our validation engine relies heavily on being notified that properties change through this mechanism and it works very well. Obviously, if you are using a different implementation other than business objects where notification of changes isn't as critical to the operation, you may have other methods for detecting change in your business model.

We also have View Models that propagate the changes from the Model where needed, but the View Models themselves are listening to the underlying Model changes.

Answer 5

I'd say in your ViewModel. It's not part of the Model as the Model is UI agnostic. The Model should be 'everything EXCEPT business agnostic'

Answer 6

I am using the INotifyPropertyChange interface in a model. Actually, a model property change should be fired by the UI or external client only.

I've noticed several advantages and disadvantages:

Advantages

Notifier is in the business model

1. As per domain driven, it is right. It should decide when to raise and when not to.

Disadvantages

The model has properties (qty, rate, commission, totalfrieght). Totalfrieght is calculated using qty, rate, commission change.

1. On loading values from db, total frieght calculation is called 3 times (qty, rate, commission). It should be once.

2. If rate, qty is assigned in the business layer, again notifier is called.

3. There should be an option to disable this, possibly in the base class. However, developers could forgot to do this.