In our WPF application we want to use the basic MVVM pattern. We were discussing it and some uncertainties about ViewModel/View relationship and validation came up. Would you say the following is a good understanding of it? Every View has one and only one ViewModel and the ViewModel's purpose is to provide its View with data and handle all of its View's events and commands. (Are there instances where one ViewModel services two Views, e.g. a standard XAML input form view and a CSV Import which provides the same data as the form and thus needs to have the same validation?) Validation is handled solely by the ViewModel when e.g. the view throws a ChangedFocus or SaveButtonPressed event, etc. The Model is pretty dumb , simply being the data structure based on one or more tables from the database, but the model itself doesn't handle validation, for instance. It is even the ViewModel that builds up and holds the ObservableCollection of objects e.g. "Customers" and not the Model itself. Any feedback appreciated.

Reputation: 193302

ViewModel/View relationship and validation

In our WPF application we want to use the basic MVVM pattern. We were discussing it and some uncertainties about ViewModel/View relationship and validation came up. Would you say the following is a good understanding of it?

Every View has one and only one ViewModel and the ViewModel's purpose is to provide its View with data and handle all of its View's events and commands. (Are there instances where one ViewModel services two Views, e.g. a standard XAML input form view and a CSV Import which provides the same data as the form and thus needs to have the same validation?)
Validation is handled solely by the ViewModel when e.g. the view throws a ChangedFocus or SaveButtonPressed event, etc.
The Model is pretty dumb, simply being the data structure based on one or more tables from the database, but the model itself doesn't handle validation, for instance. It is even the ViewModel that builds up and holds the ObservableCollection of objects e.g. "Customers" and not the Model itself.

Any feedback appreciated.

Upvotes: 6

Answers (3)

Kent Boogaart

Reputation: 178650

Are there instances where one ViewModel services two Views

Skinned applications may leverage this ability.

The Model is pretty dumb but the model itself doesn't handle validation

The model can be as smart as you like. And it can include "validation" to ensure integrity, but that validation won't include messages that are surfaced in the UI.

Upvotes: 1

John Myczek

Reputation: 12256

Every View has one and only one ViewModel

I think if you are strict about your following of the pattern then each view will have just one ViewModel. We have a case in our application where requirements changed mid-stream and it was easiest to have the View reference two different ViewModels. Depending on how you implement the pattern this may or may not be possible.

Are there instances where one ViewModel services two Views

Yes, this is one of the advantages of the pattern.

Validation is handled solely by the ViewModel

Not necessarily. We chose to have our model classes implement IDataErrorInfo and do the validation themselves. This insures that no matter where the Model class is used the validation will be the same. If the validation ever needs to change it is in just one place.

The Model is pretty dumb

It is only as dumb as you want it to be. You can include validation and business rules in the model if you like.

Upvotes: 6

Methos

Reputation: 51

I do agree with all said above. Just one comment: your view model can use another view models inside. Using this approach you can divide your view in couple regions which are served with different view models. Just use ContentPresenter, bind it to the needed view model property (which gets needed view model) and use DataTemplate to associate needed view with your view model.

Upvotes: 3

ViewModel/View relationship and validation

Answers (3)

Related Questions