64

I have clear idea about View and ViewModel in MVVM pattern. I am planning to implement MVVM pattern in my application. I'm facing an issue regarding the model. I have .xml file which is parsed and the information is displayed in the View.

I need to be notified about the changes in the model for the first time only. From onwards on demand I need to be notified.

So how to implement the model?

Should I implement INotifyPropertyChanged interface in model class also? (I read that model should not implement INotifyPropertyChanged interface, since it is WPF specific)

akjoshi
  • 15,374
  • 13
  • 103
  • 121
Syed
  • 953
  • 1
  • 8
  • 11
  • 4
    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) – H H Aug 03 '11 at 14:51
  • 1
    Definitely worth reading the other question linked above. – CAD bloke Apr 26 '16 at 01:53

6 Answers6

59

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 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.

akjoshi
  • 15,374
  • 13
  • 103
  • 121
  • 1
    Have a look at the http://polymod.codeplex.com/. You can have your model as a POCO, wrap it with a Polymod proxy which gives you INotifyPropertyChanged and even IDataErrorInfo out-of-the-box. It saves a lot of coding in your Model/ViewModel. – Arnaud May 03 '12 at 11:50
  • what would do if you are using a DTO ;Would you polute it with INotifyPropertyChanged? I tried to share some models implementing this with Compact Framework and failed – GorillaApe Oct 22 '12 at 12:52
  • 1
    this is the answer I was looking for. I have a model that's being used all over the place and it has a list of items, that when they change the vm does not update. the only way of solving this is adding inotifypropertychanged to the model.... Or to inherit the model in to a viewmodel, but prefer to keep amount of code down.... if there is another way, I'm happy to hear about it... – user1841243 Jan 08 '14 at 15:50
  • 1
    I know you're quoting from Microsoft; however, there are some serious implications to allowing your model implement, specifically `IDataErrorInfo`. The philosophy behind `IDataErrorInfo` requires that the model can exist in an invalid state at some point in time which can make it easy for the model class to become anemic. See also [Mark Seemann's Blog](http://blog.ploeh.dk/2010/07/12/DomainObjectsandIDataErrorInfo/) and [Martin Fowler's Article](https://martinfowler.com/bliki/AnemicDomainModel.html). – Nicholas Miller Jul 06 '18 at 16:33
  • @NickMiller +1 Agree with `IDataErrorInfo` usage, it's more complex with that kind of functionality and must be implemented carefully; personally, I have not used that with models, as validation can vary a lot depending on with what view a model class is used, design etc. and I too prefer to have validations in viewmodel. But in some scenarios, I might still prefer to have it in models if it saves a lot of rework and depending on various other factors (some are mentioned in the comments of those articles you referred). Thanks for pointing that out :) – akjoshi Jul 10 '18 at 10:21
  • Its hard to remember but I think my answer was more in relation to `INotifyPropertyChanged` and didn't think much about `IDataErrorInfo` (in the quote) at that time; And, still after 7 years and worked in many more WPF projects (with and without this kind of Model implementation), I still stand by my answer wrt `INotifyPropertyChanged` and prefer it that way. – akjoshi Jul 10 '18 at 10:22
  • 2
    Yes, I didn't mean to revive an old post, but wanted to make sure people coming by would know the risk with `IDataErrorInfo`. I do agree that `INotifyPropertyChanged` should be fine (and preferred) in the model - same with `INotifyCollectionChanged`. The only problem I have is with `IDataErrorInfo`. From my perspective, this interface returns user-friendly error messages (presentation logic) which makes it more appropriate for a view-model. I'm glad to see that your experience corroborates my new findings. :) – Nicholas Miller Jul 10 '18 at 12:42
16

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.

akjoshi
  • 15,374
  • 13
  • 103
  • 121
Pieter Müller
  • 4,573
  • 6
  • 38
  • 54
  • 5
    what if I have ObservableCollection of models in my ViewModel, and I want to change these objects?... I have to implement INotifyPropertychanged on those models then, making separate layer just for that is non sense. – Konrad Mar 29 '18 at 12:13
15

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.

Ehsan
  • 767
  • 7
  • 18
Firoz
  • 7,224
  • 10
  • 41
  • 56
9

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

Dan
  • 1,130
  • 2
  • 20
  • 38
Klaus78
  • 11,648
  • 5
  • 32
  • 28
3

This is a classic argument between the "pure" MVVM coders and others.

I tend to go by the books whenever I can because most of the times that makes sense. However, in certain scenarios improvising the code according to the needs reduce a lot of duplicate code.

In your case, you can read the XML to a model class and either make a copy of the model class to the viewmodel, or copy the properties you want from the model to the view model. This way you have control for updating the UI/model. If you follow the first approach you need to have Inotifypropertychanged implemetned in your model class and it is acceptable.

Having said that I would try my level best to follow the second approach because that would give me precise control over all the properties which is displayed/manipulated in the view. Also, I will feel much better that I am not breaking the MVVM pattern.

Jimmy
  • 3,224
  • 5
  • 29
  • 47
3

I'm not sure about what you mean. In the VM you may have either the INotifyPropertyChanged, or DependencyProperty-es (in this case the VM must derive from DependencyObject). Make no sense having both. Also doesn't make sense having none of them.

In the model, you may do whatever you want. The ability to fire/receive events is good, but not always you can rely on them. Basically the model is depending on the source data and related stuffs, while the viewmodel has the load of interface the model with the presentation layer. Since WPF works upon events, at least the VM must provide some notification mechanism.

akjoshi
  • 15,374
  • 13
  • 103
  • 121
Mario Vernari
  • 6,649
  • 1
  • 32
  • 44