2

Almost every MVVM example I've come across has both the Model and ViewModel implementing INotifyPropertyChanged.

Other sources (ones which focus on domain modeling) seem to suggest that Models should be incredibly plain (something to do with separation of concerns?) with essentially no references to anything. Unfortunately, those sources don't use MVVM.

I'm trying to reconcile the two.

-I'm relatively new to programming and completely new to design patterns and the like so please try to go easy on me.

Edit: Let me rephrase my question. Given that the answer to the above seems to be "sometimes one and sometimes the other," WHEN should you do one and and when should you do the other. Also, how would each be implemented?

(That isn't answered in the other post. It just has them arguing with each other).

rayden54
  • 251
  • 1
  • 5
  • 14
  • possible duplicate of [In MVVM should the ViewModel or Model implement INotifyPropertyChanged?](http://stackoverflow.com/questions/772214/in-mvvm-should-the-viewmodel-or-model-implement-inotifypropertychanged) – Jason Watkins May 17 '15 at 04:38
  • [duplicate](http://stackoverflow.com/questions/772214/in-mvvm-should-the-viewmodel-or-model-implement-inotifypropertychanged) – Eldho May 17 '15 at 04:38
  • `INotifyPropertyChanged` (.NET 2+) pre-dates WPF (.NET 3+) and so as a design pattern pre-dates MVVM in that respect. Use `INotifyPropertyChanged` anywhere you wish –  May 17 '15 at 04:51
  • Convenience. Same goes with INDEI. If you don't, you end up having to map types back and forth (what a PITA) or creating a wrapper for your models that supports INPC. –  May 18 '15 at 16:01

2 Answers2

0

Models have to implement INotifyPropertyChanged to inform the view model that they have changed. If the model doesn't implement INotifyPropertyChanged (or another equivalent interface), then the view model is stuck using polling or other similarly inefficient methods to detect changes in the model state.

This MSDN page may be useful reading to further understand the roles of the various components that make up the MVVM pattern.

Jason Watkins
  • 3,766
  • 1
  • 25
  • 39
0

I have no idea if this is a best practice, but I have my ViewModel set up so that it is the only active entity. The Model is only directly changed when created by reading from a database (and then loaded into a ViewModel), or before saving to database (extracting from ViewModel, modifying Model properties that only matter to the database, like foreign keys).

If for some reason you desire being able to have multiple ViewModels connected to the same Model or have a need to change a Model from under a ViewModel, then you'd have a good reason to implement INotifyPropertyChanged on the Model.

I'm a relative amateur, so take what I say with a grain of salt. But this is what I've been gathering, and enforcing this separation has, I think, made my code cleaner and easier to understand and debug. So for my own projects, I'm going to try avoiding implementing INotifyPropertyChanged on my Models if I can avoid it.

Nick Bauer
  • 1,027
  • 8
  • 13