What's the point of having models in WPF?

Question

So far I have yet to see the value of having models in WPF. All my ViewModels, by convention, have an associated Model. Each of these Models is a virtual clone of the their respective ViewModel. Both the ViewModel and Model classes implement INotifyPropertyChanged and the ViewModel just delegates everything to the Model anyway.

Why bother having Models then? Why can't I just move my Model logic up into the ViewModel and call it a day?

It seems rather redundant (that is, not DRY) to have MVVM, and just use VVM by default unless some special edge case demands a Model.

If using explicit model classes better supports unit testing, for example, or some other best practice, I can see the value.

Answer 1

If you think of it as an abstraction, let's say you need to build a screen to display a list of Employees and make a Selection, Search or Filter. Then we break it up in components. You will require:

1. An Employee class (Model)
2. An EmployeeManagementViewModel to prepare and present your list of Employees and manage state changes for your View (e.g. can contain a SelectedEmployee, Filter Search text, etc) to be used by your EmployeeManagementView
3. A list of Employees (Which will live in your EmployeeManagementViewModel)

Most likely you will already have an Employee class. If that's the case then you just need to expose that model in your EmployeeManagementViewModel as an ObservableCollection of Employees.

In case you don't already have an Employee class you may decide to create an EmployeeViewModel and add your Employee properties there like FirstName, LastName, etc.

Technically this will work but conceptually it bothers me because an EmployeeViewModel is not an Employee (it contains an employee). If you're abstracting reality then, the blueprint of an Employee should not include properties or methods to be used by a View. To me Employee should be a POCO which could implement INotifyPropertyChanged and nothing more than that. You're separating View state from the Model itself. Having an Employee POCO makes it easier to UnitTest, create mock employees, map it to a database table through an ORM, etc.

As the name implies the ViewModel is the model for your View and the Model is the model for your business domain

Anyway that's how I see it. When I started doing MVVM work I had that same question but over the years seems like it makes sense.

Answer 2

The model is just the low level application data.

The view model is more specific.

• It's like a window tapping into the data tailored for the view.
• It also augments the model with details needed for the view. A good example is pagination.
• A model can have more than one view model. These view models would offer different aspects of the data.
• You can create a mashup of different data sources. A view model cleanly façades the models involved.

That means there is no 1:1 relationship between models and view models.

So, if you just display the low level data without a lot of additional logic, features, summaries, aggregations, filters, etc. you can do away with view models and just use the model directly. This seems to be the case with your project.

Answer 3

The model can be auto-generated (Entity Framework), or it might not be a specific class at all (think of a DataTable).

I assume that if you say "I don't use a model", you do in fact use a model, you just don't call it that way.

Answer 4

First of all, even in MVVM you can expose your Model directly in the VM and bind through it to the Model. {Binding MyModel.MyModelsProperty} where DataContext = ViewModel that way you don't have to necessarily wrap everything unless that is just your style to do so.

The ViewModel and Model have different responsibilities. For example, consider designing a file explorer with a tree view of folders. Each node in the tree view is a Directory/Folder. The directories are the models and they have properties related to the file system. The ViewModel may wrap or expose these properties for the TreeView nodes to display (For example the Name of the directory), but it also adds additional information such as "IsEditing" and "IsExpanded" to determine the state that the node is in.

Answer 5

You're just talking about one pattern in MVVM, actually there are more.

In Stateful viewmodel you don't actually delegate things to Models, Viewmodel itself maintains its state, so as you said in this pattern you can almost ignore the model as you can have state in VM itself.

To create isolation between business logic and presentation, data should be removed from the view. The stateful view model pattern moves data into the view model using XAML data binding. This allows the view model to be tested without constructing a view, and it allows the view to change with minimal impact on the business logic.

In Stateless viewmodel you delegate the calls to Model, which is what you're probably referring to.

Note that you don't necessarily implement INotifyPropertyChanged in Model. Just implementing it in VM is fine as long as you don't change the properties directly in Model.

So why do we need VM and Model? VM is for supporting view like providing Commands, etc and Model is just to hold the piece of data abstract the same.

Answer 6

In general, my Models end up being a Data Access Layer, be it through Entity Framework, a WCF proxy, or some other class.

Depending on concurrency issues, the class could be static or instanced. If you can separate the behavior enough, you could "split" the DAL classes into a separate model for each view model, but duplicate code could become a problem.

Answer 7

Wikipedia: MVVM

Model: as in the classic MVC pattern, the model refers to either (a) a domain model which represents the real state content (an object-oriented approach), or (b) the data access layer that represents that content (a data-centric approach).

Your ViewModel isn't a substitute for your domain Model. It acts as an intermidiate between your view and the model, including commands, binding collections to your view, validation, etc.

Your domain model should also be reusable across ViewModels. If you implement it all in the VM you will end up abusing the DRY principle by sharing specific VM logic across multiple VMs.

Answer 8

In my experience when you just use Domain models as the ViewModel (as a property of the VM) you end up with a lot of Keys that require you to either go get the text value and store somewhere else or you end up adding the property to the VM anyway. Your view typically has more info than just one single domain model (e.g. related objects, display values, text status values etc..), something that the Domain model has no need for and would ultimately weigh it down. The view model is dedicated to the needs of the view, it keeps coding the View simple and non-complex.