21

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?

  • 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
25

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.

  • 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
  • 9
    @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
  • 4
    @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
16

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

8

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.

7

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.

2

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.

1

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.

  • this post is rather hard to read (wall of text). Would you mind editing it into a better shape? – gnat May 4 '18 at 20:52
  • There you go, Cheers. – Ivan Carmenates García May 10 '18 at 15:18

protected by gnat May 4 '18 at 20:51

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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