Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
Personally I find exposing the properties of the model to result in a good seperation of your data layer and logic layers. – Alex Hope O'Connor Dec 5 '11 at 16:47
up vote 16 down vote accepted

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.

share|improve this answer
I like your answer. +1 for mentioning Edit/Save Screen.. But then it would be daunting to write the properties twice - once in model and again in view-model. It would also increase the development time. Do you think it is justifiable to do so...? – Pravin Patil Dec 5 '11 at 14:58
@Pravin Patil - fwiw, every time I've taken that shortcut, I've cursed myself later when I had to go back and fix it. There's comparatively little effort to re-implement the properties on the ViewModel, especially if they're read-only (because you can use auto-implemented properties with a private setter). The fact is, in most cases the Model is a different data structure than the ViewModel. Leave yourself the flexibility to change the Model without affecting the View. The less you have to change the View, the better, because the View is hard to test. – Scott Whitlock Dec 5 '11 at 15:53
@Scott Whitlock: I've been developing WPF applications with NHibernate for two years now and never had any troubles whatsoever binding directly to the model. In fact, when a model property changes it's mostly the same effort for the change, regardless of what you bound to. And when I really need to have some routing done in the ViewModel itself later on, then it was not worth to invest the time before I needed it. I follow the YAGNI (yet) approach and have no difficulties. I think you and the others here are being a bit dogmatic about this issue. – Falcon Dec 5 '11 at 17:00

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).

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.