Question

Let’s say I’ve got a View. It’s DataContext is bound to a ViewModel and the ViewModel exposes a Model property.

• Is it MVVMlike to bind fields in the View to properties in the Model (e.g. Binding Path=Model.FirstName)?
• Should the Model implement INotifyPropertyChanged?

My team are using Prism and MVVM in WPF. A lot of the Prism examples bind indirectly to the Model. I personally have my doubts that this is the correct approach. I think stuff in the model should expose behaviour (not just at the property level) and should communicate important events by, er, events – that clients can subscribe to or not.

I think that by having domain/model objects implement INotifyPropertyChanged somehow says to the world that it’s UI/UX aware and kind of introduces some redundancy in the ViewModels.

What do you think? What works for you? A clear distinction between View/ViewModel/Model or a hybrid as used by the Prism examples?

Answer 1

I have seen many people implementing INotifyPropertyChanged directly in their Model and similarly I have seen people doing it in ViewModel as well.

I prefer and do this(implement INotifyPropertyChanged) in ViewModel. I agree with you it sometimes create redundancy in ViewModel but I prefer a clear distinction/separatation between ViewModel and Model and what their purpose should be. To me Model is just literally a Model. It is just representation of my Business Data nothing more nothing less. To me it should not cause any change in View (through notify property changed event). View should talk to ViewModel and ViewModel should use Model. I don’t like View directly affecting the Model. I don’t like using Model.FirstName because to me it seems like going against MMVM by telling View what is in Model