MVVM duplicating Model properties in ViewModel

Question

It seems that there is a guidance that a model should not expose its entities to View, and that all required properties should be duplicated in ViewModel

Example:

Product
Id {get; set;}
Name {get; set;}
.......


ProductViewModel : ViewModelBase
Id {get; set;}
Name {get; set;}
.......

Why is this required? I can understand this if Model doesnt implement INPC, but if it does, then I find this quite unnecessary.

score 8 · Accepted Answer · answered Jul 03 '12 at 06:20

8

When the View is bound to the Model:

If the View needs to change or you have multiple views a change to the Model will cause changes to all the Views bound to that Model.
From the View's perspective, the object it is bound to might not be that intuitive; when you need to add a properties and/or commands to the the object do you add those to the ViewModel and keep the 'original' properties in the Model or do you modify the Model?

Having a ViewModel gives you an extra abstraction between a single Model and multiple (versions of) Views

All in all it is just a guideline but be aware that what seems OK today might be not so great when you need to modify/update the application.

answered Jul 03 '12 at 06:20

Emond

50,210
11
84
115

I consider Model to be anything that is provided by an external source (proxy classes, repository, stream) INPC is only needed when I want the View to be updated by changes in what is bound to it. I never bind the Model to the View for reasons in my answer, that is what the ViewModel is for. – Emond Jul 04 '12 at 04:09
Hi Erno, sorry for late response, I was on vacation. Your first point is strong. Answer to second point is: yes. If I may ask this: if you need a short info on customer, for example only code, name and Id, would you have a CustomerBasicInfoViewModel with only this three properties, use full Customer object as DTO (with all properties), or you would also have CustomerBasicInfo in Model, to preserve memory? – Goran Jul 13 '12 at 17:42
As always: it depends. In WPF (a desktop app) I wouldn't worry about a few (kilo)bytes of memory but I would worry about bandwidth first. Most of the time it's the bandwidth that dictates the size of objects. – Emond Jul 14 '12 at 05:59

score 5 · Answer 2 · answered Jun 29 '12 at 14:43

5

Guidance, is just that. It depends on the situation at hand. Purists will argue that separating the model entirely from the view allows the model to change without the view changing.

I tend to only proxy model properties if I have to (either INPC or some view specific logic like the model has FirstName and LastName but no FullName)

Otherwise I bind to the Model (which is a public property on the ViewModel). If my situation changes and I need to encapsulate something then i refactor when I have a need.

I do always try to ensure there is a ViewModel in place (even if it only exposes the model) so refactoring is easier later.

answered Jun 29 '12 at 14:43

Adam Mills

7,719
3
31
47

Hi Adam, sorry for late response, I was on vacation. So, how would you handle situation where you need to display a collection of Customers on Invoice View, where only a very basic info is required (example Code, Name and Id). Would you have a CustomerBasicInfo in yout model, or...? – Goran Jul 13 '12 at 17:45
Usually the model is dictated to you, by your domain, by a webservice etc. So you create a viewmodel to wrap the model and make presenting the data easier for the view (e.g. adding properties like selected, visible etc). If you have a read-only view and your model is sufficiently similar to the views structure then you can always use it now and replace it later with a viewmodel as your specs change. Beware of letting UI concerns creep into your model – Adam Mills Jul 13 '12 at 21:19

score 2 · Answer 3 · answered Jul 02 '12 at 05:35

2

My question is, why are your models implementing INPC? Do they need to?

Usually models are just a DTO and don't need any change logic.

Also if your base implementation of INPC is coming from an MVVM framework, but your models exist in a shared assembly does that assembly then need a reference to your MVVM framework, and potentially other WPF assemblies too?

The scenario we had was a set of shared objects representing our data on both the server and the client side. Client side was a WPF app so that was fine but for the server side was a service, so we didn't need INPC.

answered Jul 02 '12 at 05:35

Cameron MacFarland

70,676
20
104
133

Hi Cameron, sorry for late response, I was on vacation. Well, somebody must implement INPC, eithee Customer (Model) or CustomerViewModel. Do we need DTOs in every scenario? If you want to introduce reference to MVVM framework from Model, you can, but is not required. INPC implementation is very simple. ViewModelBase from MVVM framework will still be used as base for VIewModels. My problem is this: if I ask a question "should I duplicate all model properties in VM", and the answer is yes, regardless the application type, I am wondering - why? – Goran Jul 13 '12 at 17:35

score 0 · Answer 4 · answered Oct 04 '13 at 07:16

0

Your ViewModel is incorrect. If you already have a Model of Product type, you can simply define something like this in your ViewModel: public Product Product {...}

answered Oct 04 '13 at 07:16

Rinat Galyautdinov

255
2
2

3

That is the core of his question! Exposing the Model to the View bypasses the ViewModel's responsibility. – Emond Oct 04 '13 at 07:20

MVVM duplicating Model properties in ViewModel

4 Answers4

Linked