What is the point of having both a model and a ViewModel in MV-VM?

Question

It always seems to me tempting to combine a model and a presentation model into one class, and I see no shortage of this.

There must be a good reason for separating them. What am I missing?

Answer 1

The first real disadvantage of this is the lack of separation of problems. And soon this will lead to redundant code. Now, I said, I saw many times when developers used their Model objects as ViewModels. And if we are completely honest with ourselves, in a very thin application, sharing these concepts can actually lead to more redundancy.

The best thing you can do is to learn more about MVVM and its roots in MVC and Presentation Model, but I think you are very interested in what you ask this question and that you are not blindly following the dogma. In fact, I often don’t even start with MVVM at all when I start a small application. I often start with a hundred lines or so in the code, forcing the concept, and then start refactoring in MVVM.

In more detail about your question , the model and the presentation model have conceptually completely different goals. The model includes your business logic (domain logic), data model (objects, attributes and relationships) and the level of data access. ViewModel is essentially an adapter for the model, adapting it for specific View purposes. In some cases, you may have 3 different views (and view models) for a given data model object. Each view model will adapt the same attributes to the model object for specific purposes of that particular view.

Answer 2

ViewModel is a soft copy of View , i.e. if you have an updatable ListBox in the view, you will have an ObservableCollection in your ViewModel that represents the list of items in the list. Similarly, if you have a Button on View , the VM will contain Command .

Model will actually be what the data that View shows. Thus, the type set in your VM has, you can call the Model class.

eg. a Employees ListView is a View and has a data context that is an instance of the EmployeeViewModel class that has the ObservableCollection property of the Employee class, where the Employee class becomes Model .

Typically, there is a 1-1 relationship between the View and VM relationships and 1-N between the VM and Model .

Answer 3

The model is the scope of your application and therefore contains your domain logic, such as business rules and checks. ViewModel is the model for your view. It handles the interactions between the user and the view, that is, when the user clicks the button, the view model processes this interaction and may or may not make changes to the model. Usually in OO, you want your objects to have only one responsibility.

In WPF, ViewModel typically implements the INotifyPropertyChange interface, which is then viewed when viewing for any changes. You would not want the model to implement this interface, since it is not associated with your domain.

Another reason for the separation is that sometimes you may not need to present all the data in the model. For example, if your model provides 15 properties, but in one of your views, the user should see only 5 of these properties. If you put your model in the ViewModel, the view will be displayed for all 15 properties, whereas if you encapsulate the model in the ViewModel, only 5 properties will be displayed in the view.

There are probably many more reasons, but overall it's a good design to keep them out of the way. With that said, if your application is small enough, you can walk away with the model and ViewModel together to reduce code redundancy.

Answer 4

My simple answer (and I do not pretend that WPF Guru ) would be that in WPF you will need a virtual machine when:
1. You do not want to expose your entire model to a specific look
2. Your model is not in the "WPF style" (does not implement INotifyPropertyChanged, has no observable collections, or no commands).