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?

Answer 1

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

Answer 2

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.