ViewModel vs Domain Entities

Question

Before I start, I want to say that I know what a ViewModel is, and what its purpose is, but this scenario makes it redundant .. please read on :)

I am working on an ASP.NET MVC4 application, and have come across some headache with regards to PagedList, Domain Entities and ViewModels.

Basically, the PagedList.MVC plugin does not work nicely with AutoMapper, and I have to do a lost of extra work to get it to work as I want it.

But then I thought, do I even need a ViewModel class when all the properties on the Domain Entity in question are required?

Of what benefit is a ViewModel when every single property on your Domain Entity is required by the View?

Dumb question but what are you using to access your database? Entity Framework? If so, Entity Framework supports projections that can map directly into your ViewModel. — Khalid Abuhakmeh, Feb 20 '14 at 14:36
When your requirements or domain entities change and they're not the same as what you need to display, then what? — Big Daddy, Feb 20 '14 at 14:36
@BigDaddy, that's a good point but if it is what he needs to display then it saves trouble, what Fowler calls the shotgun-change smell. Where one small change requires changes to many classes. — dove, Feb 20 '14 at 15:09
@dove...If the domain never changes, fine, don't use a VM, If the view will always display the domain, fine, don't use a VM. Suppose the domain is refactored (it happens) into more granular classes and the view needs to display pieces from many entities. Only the VM needs to be updated. I don't think this is smelly. — Big Daddy, Feb 20 '14 at 15:21
@BigDaddy you're preaching to the converted, I completely agree with you. However, I can see how this might not be useful in certain circumstances and for some folk. — dove, Feb 20 '14 at 15:25
In my scenario, the point about future proofing is the winner. Thanks Big Daddy and dove :) — J86, Feb 20 '14 at 17:19

score 2 · Accepted Answer · answered Feb 20 '14 at 14:24

2

It can be a matter of opinion, I like using view models (and DTOs) which gives the following benefits:

I'm sure that all the data required for the view is loaded and not a proxy etc.
If crafted correctly the DTOs provide a much smaller graph to store in a cache (may not apply to your setup)
It allows my view models to vary greatly from Domain objects, often they are composites and are quite flatenned and to freely alter them without affecting any other part of my application.

Now to counter the above, and many would, you could work directly with your domain objects. I'd probably recommend this too if you find your view models are simply one to one likenesses of your domain and you don't see any benefit in the above.

As usual it depends on your setup

your team
what makes you productive
tools used, ORM used if at all
size and duration of project
experience
etc, etc, etc

answered Feb 20 '14 at 14:24

dove

20,469
14
82
108

All your points are valid, but in my scenario, they are all mute .. I think? – J86 Feb 20 '14 at 14:27
yes, it sounds like you should at least try working without if it's only getting in your way, i've added an "it depends" caveat to the answer – dove Feb 20 '14 at 14:29
I recently was on a small team with developers with 15+ yrs experience. 90% of our Domain and VM's were a 1 to 1 relationship. Yea it created an extra foreach statement to transfer the two but I like the separation. Any supporting thoughts/reasons why a 1 to 1 transfer like this is done – CSharper Feb 20 '14 at 16:11
1

@CSharper if you're using an ORM it makes sure that you data is loaded. If it's very useful in the 10% then a consistant style can help with a larger team too. It does allow splitting the work easier as well, allowing someone to focus on the UI and others on the Domain. – dove Feb 20 '14 at 16:32

Yorro · Answer 2 · 2014-02-21T08:41:31.607

I would just like to add that for small projects, it is okay to just have your own ViewModel and work with that. You can later you can separate the entity if it calls for it.

To many developers adding new layers without weighing in the pros and cons, later they start noticing the lag then doubts happen. MVC itself is already a separation-of-concern.

Having a separate DomainEntity solves a different problem where the UI no longer maps 1-to-1 to the an entity, consider the following.

Version 1
Domain              | Presentation  
--------------------------------
User.FirstName      | User.Name
User.LastName       |
User.PositionTitle  | User.PositionTitle

The example demonstrates that the domain and the presentation are no longer mapped 1-to-1. In the future, you might have domain modifications such as the following:

Version 2
Domain              | Presentation  
--------------------------------
User.FirstName      | User.Name
User.LastName       |
Position.Title      | User.PositionTitle

Based on the example above (version 2), notice that the presentation was not modified. Having a separated domain model improves the interface stability. It can even decrease the cost of changes for refactoring scenarios.

Advantage of the ViewModel

The beauty of ViewModel is that it decouples your domain from the presentation, this benefit is more obvious when employed in large projects, where different developers handle different parts of the system (separate GUI team for example)

one small change requires changes to many classes.

This is one of the disadvantage of decoupling your entities, it creates duplication of code. The extra coding has a huge cost and the benefits has to be evident to be worth it.

ViewModel vs Domain Entities

2 Answers2