In MVVM should the ViewModel or Model implement INotifyPropertyChanged?

Edward_Tanguay_4639 0
Viewed 54056

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?

inotifypropertychanged mvvm wpf .net c#
17 Answers

I'd say quite the opposite, I always put my INotifyPropertyChanged on my ViewModel - you really don't want to be polluting your model with a fairly WPF specific feature like INotifyPropertyChanged, that stuff should sit in the ViewModel.

I'm sure others would disagree, but that's the way I work.

Beepcake_265070
user_931410

I think MVVM is very poorly named and calling the ViewModel a ViewModel causes many to miss an important feature of a well-designed architecture, which is a DataController that controls the data no matter who is trying to touch it.

If you think of the View-Model as more of a DataController and implement an architecture where your DataController is the only item that touches the data, then you would never touch the data directly, but always use the DataController. The DataController is useful to the UI but not necessarily only for the UI. It is for business layer, UI layer, etc...

DataModel -------- DataController ------ View
                  /
Business --------/

You end up with a model like this. Even the business should only touch the data using the ViewModel. Then your conundrum just goes away.

user_3757270

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.

Steve_Mitcham_101560

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'

user_289010

Implementing INPC in models could be used if the models are plainly exposed in the ViewModel. But generally, the ViewModel wrap the models is his own classes to reduce the model complexity (which should not be usefull for the binding). In this case the INPC should be implemented in the ViewModel.

user_39870220

All properties, which are binded to my view, are in my ViewModel(s). Thus they should implement the INotifyPropertyChanged interface. Therefore the View gets all changes.

[Using the MVVM Light toolkit, I let them inherite from ViewModelBase.]

The Model holds the business logic, but has nothing to do with the view. Thus there´s no need for the INotifyPropertyChanged interface.

user_111307820
Related