42

I've read a few articles regarding the role of the (Data)Model in the MVVM pattern. However, i still could not figure what goes into the model.

Should the model implement INotifyPropertyChanged? If so, what is difference between the VM and the model?

If not, a change in the Model will not notify the VM and the View that it occured. So - considering the logic goes into the Model, it seems obvious that it should notify the ViewModel about some of it's changes. However, isn't it weird to implement INotifyPropertyChanged in both classes?

Thank you very much!

Horse Pen
  • 547
  • 1
  • 5
  • 8
  • possible duplicate of [What goes in Model in MVVM?](http://stackoverflow.com/questions/4453352/what-goes-in-model-in-mvvm) – Shekhar_Pro Feb 17 '11 at 10:21
  • Check this post : [What goes in Model in MVVM?](http://stackoverflow.com/questions/4453352/what-goes-in-model-in-mvvm/4453396#4453396) – decyclone Feb 17 '11 at 10:17
  • Thanks, i've already read it. I'm still a little confused because it seems weird to me that the model implements INotifyPropertyChanged, which seems to me as a UI-Related class – Horse Pen Feb 17 '11 at 10:19
  • 1
    Notice that (if needed) = (not recommended). – decyclone Feb 17 '11 at 10:21
  • The key is the "if needed" after the model. Of course defining when needed is an interesting problem. I think it rather depends on the interactions i.e. does a change to the view model directly trigger a change to the model that the view model might then need to be advised of (to in turn update the UI). – Murph Feb 17 '11 at 10:23
  • @Horse But it is not. INotifyPropertyChanged is located in System.ComponentModel. INotifyPropertyChanged is not a UI-Related class. It seems weird to me that people don't understand this. – Bastien Vandamme May 29 '12 at 14:06

3 Answers3

24

The model implements your business logic. The view model decorates your business logic for the purpose of displaying it and interacting with it, in a view (UI of some form, eg. web, winform, CLI). So, no, I would not say that your model should implement INotifyPropertyChanged unless it would do so as part of your core business logic.

Klaus Byskov Pedersen
  • 117,245
  • 29
  • 183
  • 222
  • So it means that modification of properties in the model should be through the ViewModel only? – Horse Pen Feb 17 '11 at 10:25
  • 3
    @Horse, yes. I know that this requires more work, but it ensures a clear separation of responsibilities and ultimately makes your software more testable. The real goal here, in my opinion, is to make sure that your business logic is implemented in one central place, namely in the model. Have in mind that the same model could be used by various view models (eg. both web and winapp). Therefore, having the view interact directly with the model could lead to the necessity of implementing UI-specific functionality in the model which only applies to one view. The view model's job is to avoid this. – Klaus Byskov Pedersen Feb 17 '11 at 10:49
  • 2
    if the business logic is in the model, so it must change values of properties. Do you suggest raising events from the model to the viewmodel so that the VM would make the change? I'm trying to figure out how can the VM be the one that modifies properties if the logic is in the model – Horse Pen Feb 17 '11 at 10:54
  • 1
    @Klaus If your model don't implement INotifyPropertyChanged could you explain me how you notify a change from the Model to the ViewModel? – Bastien Vandamme May 30 '12 at 09:18
  • @DranDane, changes to the *Model* propagate from the *View* to the *ViewModel* to the *Model*, so your *ViewModel* should already **know** that it made changes to the *Model*. – Klaus Byskov Pedersen May 30 '12 at 12:38
  • 1
    @Klaus So if your Model is modified by another thread of your application your ViewModel is not aware of this modification. You miss the information except if your thread also use the ViewModel. – Bastien Vandamme May 30 '12 at 15:58
  • @DranDane, it's an interesting question that is *outside* the "plain and vanilla" use of MVVM. I suggest you post a new question, since these comments are not a suitable place to answer it. – Klaus Byskov Pedersen May 31 '12 at 08:12
  • @Klaus Actually the question has already been asked. http://stackoverflow.com/q/6922130/196526 Thank you. – Bastien Vandamme May 31 '12 at 09:24
9

From one of your comments:

it seems weird to me that the model implements INotifyPropertyChanged, which seems to me as a UI-Related class

Change notification's used in all kinds of contexts, just not UI contexts. For instance, you might want to attach a piece of diagnostic code that logs specific changes to a TextWriter. This is easily accomplished without modification to the underlying model object if the object implements change notification.

But even in an application where it's only being used to update the UI, this pattern still makes sense. Because change notification is handled through an event, the object raising the event is decoupled from the object handling it. Your model doesn't know, and doesn't need to know, what kind of UI is using it. It's just saying, "Assuming that there's a UI, I need to tell it, whatever it is, that this property's value just changed."

So why is there a view model? Why not just bind to the model directly? In fact, you can just bind to the model directly if it implements change notification. In a lot of simple WPF applications, there doesn't need to be a separate view model - you can just implement change notification in the model and call it a day. It's when you need to decouple the UI from the underlying business logic and you start being concerned about whether or not you're violating the single-responsibility principle that the need for a view model arises.

Robert Rossney
  • 94,622
  • 24
  • 146
  • 218
  • 1
    But it is not Robert. INotifyPropertyChanged is located in System.ComponentModel. INotifyPropertyChanged is not a UI-Related class. It seems weird to me that people don't understand this. – Bastien Vandamme May 29 '12 at 14:04
  • What I meant to say was "Change notification's used in all kinds of contexts, not just UI contexts." – Robert Rossney May 29 '12 at 20:13
7

In some cases a Model must implement INotifyPropertyChanged. Imagine that you are coding client for ICQ or something like that. How is the ViewModel supposed to know, that somebody send you a message?

Difference between Model and ViewModel:

A ViewModel only simplifies the output from a Model. If the model is very simple, a ViewModel isn't necessary.

Martijn Pieters
  • 1,048,767
  • 296
  • 4,058
  • 3,343
bidacek
  • 101
  • 1
  • 6
  • 1
    Even in the case of such a messaging application, there are ways to model the Model other than having it implement `INotifyPropertyChanged`. For example, there could simply be an `event Action ReceivedMessage`. No changing properties (such as `IEnumerable ReceivedMessages { get; }`) involved at all. – stakx - no longer contributing Nov 14 '14 at 10:12