MVVM Clarification: What belongs into ViewModel, what belongs into Model?

Question

So I was looking into MVVM again after some time where I didn't really follow new developments and I noticed that the amount of tutorials/guides etc. has grown greatly. However most examples/example implementations of MVVM lack to explain something that's not really clear to me. All of these examples are pretty simple and none of them reads something form a database/file/etc.

Now for example I have some paint-like application and I save the paintings in XAML. What belongs into the ViewModel what belongs into the Model?

Does the Model supply functions to load/save the paintings from/to a XAML file?

Does the ViewModel bind to properties that the Model exposes (Color, Width, Position etc.)?

Does the validation happen in the Model or in the ViewModel?

Answer 1

From the one side, ViewModel could be a wrapper for Model object and exdend it with presentation details. For instance, if you have Model object - Pen, then PenViewModel can contain IsSelected, IsDragging properties etc.This is ViewModel as wrapper.

From the other side, ViewModel could be an abstraction over View which doesn't contain reference to particular controls. Don't forget that the one of aim of MVVM is unit testing. So for instance, you have draggable bars in your painting application. So you can abstract this feature with set of ViewModels: BarViewModel { IsSnapped, Position, IsEnabled }, BrushBarViewModel : BarViewModel, PenBarViewModel etc. And then you can cover this feature with unit tests, but all this stuff has no relation to Model. This is ViewModel as View abstraction.

Model is very close to bussiness, contains bussiness entities and logic, classes to persist entities, services. You can use different concepts in your Model, e.g. DDD (Domain-Driven-Design), Fawler's Enterprise Patterns, CQRS (Command Query Responsibility Segregation), SOA (Service Oriented Architecture).

View syncronizes state with ViewModel (Model) using binding mechanism, worst case in code behind as in PresentationModel pattern.

Bases on this, answer to your questions is gonna be:

Does the Model supply functions to load/save the paintings from/to a XAML file?

No. Model doesn't have direct reference to any XAML files.

Does the ViewModel bind to properties that the Model exposes (Color, Width, Position etc.)?

No. Binding is mechanism of View synchronization. So you need to bind View to those properties. You can bind View directly to Model, or to ViewModel wrapper.

Does the validation happen in the Model or in the ViewModel?

Wherenever. If your control support validation you can validate on View layer, e.g. DateTimePicker doesn't allow to select incorrect date. You can write custom validation logic in ViewModel and cover it with unit tests. Also, validation can be on Model level,as additional check, because Model cann't be in invalid state.

Answer 2

The ViewModel is the representation of the model which is suitable for the presentation technology you're using.

In your example I believe the Model would not provide the functions to load/save the paintings from/to a XAML file. This would be performed in a Data Access Object/Repository which would be called upon by the ViewModel taking Model instances as input. This bit is often variable though and depends on what your Model classes look like.

The ViewModel itself usually doesn't make use of data binding. It simply exposes the Model to the View in a way which is helpful for the the presentation (View) technology. In the case of WPF/Silverlight that basically means it implements the INotifyPropertyChanged interface.

Validation is usually initiated by the View (like pretty much everything), performed in the ViewModel but often delegated by the ViewModel to the Model. Of course it is best not to repeat your validations throughout your application. The best place for common validations is the Model (refer to IDataErrorInfo). However validations which are specific to your ViewModel can be handled directly in the ViewModel.