Should we bind view to a model property or ViewModel should have it's own..?

Question

I am starting a project with following technical environment : .Net 4.0, Entity Framework 4.0, WPF with MVVM Architecture

I saw lots of examples on the net, some books with this environment. In some of the examples authors had this Idea :

1. Viemodel will have an instance of Model class (Entity Framework Entity e.g. Person)
2. Bind the WPF view controls to the properties of Model

While some authors did :

1. Viemodel will expose all the properties of the model.
2. Bind the WPF view controls to the properties of ViewModel rather than to the model directly.

So is it a good idea to let the view bind properties from model rather than viewmodel exposing its own? Or which is more preferred?

Answer 1

I think a lot of programmers first try to take the shortcut of binding directly to the model, but in my experience this has some major drawbacks. The primary problem is that if your entity model is persisted by NHibernate or similar, then as soon as the View updates the model property, then NHibernate could persist those changes to the database. That doesn't work well for edit-screens that have a Save/Cancel button. In actual fact, it may choose to wait and persist everything as a batch, but the idea is that when you change the model, you're committing your change.

So, you could still get away with binding directly to model properties on read-only screens, but then you're going to have an inconsistency.

Additionally, most models don't implement INotifyPropertyChanged so they may not be suitable binding targets if the state of the screen changes after the initial display.

Given the ease of auto-properties, I suggest always binding the View to the ViewModel, not to the Model. It's consistent, simple, and gives you the most flexibility to support changes in the future.

Answer 2

The point of a ViewModel is that it is a model of the View.

You should be binding the ViewModel to the View, not any Model properties (not directly, anyways).

Answer 3

I find both methods acceptable

Binding only to the ViewModel is the "MVVM-purist" approach and leads to better separation between layers. Binding to the Model is usually faster and more convenient.

Unless I have a good reason to fully separate the layers (size of project, future maintenance concerns, type of Model I'm working with, etc), I bind to the Model.

Answer 4

I think what you are seeing is a concept called bind through, that is if your model has a property called name and your view-model exposes this property with no additional editing or converting then you can bind through to the model so it would be.

Pseudo Code:

 {Binding: MyViewModel.MyModel.Name}

This is done to reduce the amount of 'Fluff' properties on the view model, unfortunately it is also a bad idea in the long term. The concept of a view model is to ensure that the view does not take a dependency to the model. By binding through you now must ensure that your model contains a property called name otherwise your implementation will break.

If you only bind as far as the view-model however, you can change out the model and the view would never know as it will only ever see the property named Name on the view-model.

Now this can be mitigated in certain circumstances were your model is based off an interface. So if the interface had a IBaseDetails which exposed the property ModuleName then you could:

Pseudo Code:

 {Binding: MyViewModel.MyModel.ModuleName}

As long as any of the Models you make satisfy the IBaseDetails interface, your golden, be aware however that this is an edge case and in general you are 90% always better to wrap your view-model around any models it covers.

Answer 5

If you're seeing a lot of friction trying to go from Model -> ViewModel, try something like AutoMapper. It removes the tedium associated with copying properties manually.

Answer 6

I got here just because I had the same doubt and I got convinced that I would always bind to view model instead of to the model.

Take the approach of Angular Reactive Form. You create a form group using some information the View Model but later you have to access form. Values to get the values and copy does values to the model using whatever auto mapper or manual I think there is no more beautiful thing than biding to properties in the view model let's say for example I have a project view page where I have project name, client name, etc.

There is a relationship between project and client since a project has a client. So at this level, I should not care about that relationship I just need to visually show the project name and client name in the view so I put 2 properties in the view model project name and client name so I bind the view controls to both of them, later I will worry about giving values to those properties in the code behind taking then from whatever structure the model has.

The same could be for updating the model in the case of save/cancel there is nothing more clean.