Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Should a View bind indirectly to properties in a Model in MVVM?

Tags:

c#

mvvm

wpf

prism

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?

like image 352
Steve Dunn Avatar asked Jan 18 '12 09:01

Steve Dunn


People also ask

What is binding in MVVM?

MVVM – WPF Data Bindings Data binding is the key feature that differentiates MVVM from other UI separation patterns like MVC and MVP. For data binding you need to have a view or set of UI elements constructed, and then you need some other object that the bindings are going to point to.

Should ViewModel know about view?

In fact - the ViewModel shouldn't care about the View at all. It should simply make data available through properties, and it's up to the View to decide what it will dynamically bind to in the ViewModels. If the ViewModel wants to tell the View something this should occur implicit through Bindings.

Can we pass view to ViewModel?

Pass the view as an interface and hold/expose that. Use a mediator to pass whatever messages necessary between the view model/view. Have the view invoke whatever methods it needs on the view model, and have the view model raise events that the view can listen to.


1 Answers

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

like image 185
Haris Hasan Avatar answered Oct 21 '22 23:10

Haris Hasan