Viewmodels in MVC/Mvvm/Separation of Layers- Best Practices

ViewModels in MVC / MVVM / Separation of layers- best practices?

tl;dr

Is it acceptable for a ViewModel to contain instances of domain models?

Basically not because you are literally mixing two layers and tying them together. I must admit, I see it happen a lot and it depends a bit on the quick-win-level of your project, but we can state that it's not conform the Single Responsibility Principle of SOLID.

---

The fun part: this is not limited to view models in MVC, it's actually a matter of separation of the good old data, business and ui layers. I'll illustrate this later, but for now; keep in mind it applies to MVC, but also, it applies to many more design patterns as well.

I'll start with pointing out some general applicable concepts and zoom in into some actual scenario's and examples later.

---

Let's consider some pros and cons of not mixing the layers.

What it will cost you

There is always a catch, I'll sum them, explain later, and show why they are usually not applicable

• duplicate code
• adds extra complexity
• extra performance hit

What you'll gain

There is always a win, I'll sum it, explain later, and show why this actually makes sense

• independent control of the layers

The costs

---

duplicate code

It's not DRY!

You will need an additional class, which is probably exactly the same as the other one.

This is an invalid argument. The different layers have a well defined different purpose. Therefore, the properties which lives in one layer have a different purpose than a property in the other - even if the properties have the same name!

For example:

This is not repeating yourself:

public class FooViewModel
{
    public string Name {get;set;}
}

public class DomainModel
{
    public string Name {get;set;}
}

On the other hand, defining a mapping twice, is repeating yourself:

public void Method1(FooViewModel input)
{
    //duplicate code: same mapping twice, see Method2
    var domainModel = new DomainModel { Name = input.Name };
    //logic
}

public void Method2(FooViewModel input)
{
    //duplicate code: same mapping twice, see Method1
    var domainModel = new DomainModel { Name = input.Name };
    //logic
}

It's more work!

Really, is it? If you start coding, more than 99% of the models will overlap. Grabbing a cup of coffee will take more time ;-)

"It needs more maintenance"

Yes it does, that's why you need to unit test your mapping (and remember, don't repeat the mapping).

adds extra complexity

No, it does not. It adds an extra layer, which make it more complicated. It does not add complexity.

A smart friend of mine, once stated it like this:

"A flying plane is a very complicated thing. A falling plane is very complex."

He is not the only one using such a definition, the difference is in predictability which has an actual relation with entropy, a measurement for chaos.

In general: patterns do not add complexity. They exist to help you reduce complexity. They are solutions to well known problems. Obviously, a poorly implemented pattern doesn't help therefore you need to understand the problem before applying the pattern. Ignoring the problem doesn't help either; it just adds technical debt which has to be repaid sometime.

Adding a layer gives you well defined behavior, which due to the obvious extra mapping, will be a (bit) more complicated. Mixing layers for various purposes will lead to unpredictable side-effects when a change is applied. Renaming your database column will result in a mismatch in key/value-lookup in your UI which makes you do a non existing API call. Now, think of this and how this will relate to your debugging efforts and maintenance costs.

extra performance hit

Yes, extra mapping will lead to extra CPU power to be consumed. This, however (unless you have a raspberry pi connected to a remote database) is negligible compared to fetching the data from the database. Bottom line: if this is an issue: use caching.

The win

---

independent control of the layers

What does this mean?

Any combination of this (and more):

• creating a predictable system
• altering your business logic without affecting your UI
• altering your database, without affecting your business logic
• altering your ui, without affecting your database
• able to change your actual data store
• total independent functionality, isolated well testable behavior and easy to maintain
• cope with change and empower business

In essence: you are able to make a change, by altering a well defined piece of code without worrying about nasty side effects.

beware: business counter measures!

"this is to reflect change, it's not going to change!"

Change will come: spending trillions of US dollar annually cannot simply pass by.

Well that's nice. But face it, as a developer; the day you don't make any mistakes is the day you stop working. Same applies to business requirements.

fun fact; software entropy

"my (micro) service or tool is small enough to cope with it!"

This might be the toughest one since there is actually a good point here. If you develop something for one time use, it probably is not able to cope with the change at all and you have to rebuild it anyway, provided you are actually going to reuse it. Nevertheless, for all other things: "change will come", so why make the change more complicated? And, please note, probably, leaving out layers in your minimalistic tool or service will usually puts a data layer closer to the (User)Interface. If you are dealing with an API, your implementation will require a version update which needs to be distributed among all your clients. Can you do that during a single coffee break?

"lets do it quick-and-simple, just for the time being...."

Is your job "for the time being"? Just kidding ;-) but; when are you going to fix it? Probably when your technical debt forces you to. At that time it cost you more than this short coffee break.

"What about 'closed for modification and open for extension'? That's also a SOLID principle!"

Yes, it is! But this doesn't mean you shouldn't fix typo's. Or that every applied business rule can be expressed as an sum of extensions or that you are not allowed to fix things that are broken. Or as Wikipedia states it:

A module will be said to be closed if it is available for use by other modules. This assumes that the module has been given a well-defined, stable description (the interface in the sense of information hiding)

which actually promotes separation of layers.

---

Now, some typical scenarios:

ASP.NET MVC

---

Since, this is what you are using in your actual question:

Let me give an example. Imagine the following view model and domain model:

note: this is also applicable to other layer types, to name a few: DTO, DAO, Entity, ViewModel, Domain, etc.

public class FooViewModel
{
    public string Name {get; set;} 

    //hey, a domain model class!
    public DomainClass Genre {get;set;} 
}

public class DomainClass
{
    public int Id {get; set;}      
    public string Name {get;set;} 
}

So, somewhere in your controller you populate the FooViewModel and pass it on to your view.

Now, consider the following scenarios:

1) The domain model changes.

In this case you'll probably need to adjust the view as well, this is bad practice in context of separation of concerns.

If you have separated the ViewModel from the DomainModel, a minor adjustment in the mappings (ViewModel => DomainModel (and back)) would be sufficient.

2) The DomainClass has nested properties and your view just displays the "GenreName"

I have seen this go wrong in real live scenarios.

In this case a common problem is that the use of @Html.EditorFor will lead to inputs for the nested object. This might include Ids and other sensitive information. This means leaking implementation details! Your actual page is tied to your domain model (which is probably tied to your database somewhere). Following this course, you'll find yourself creating hidden inputs. If you combine this with a server side model binding or automapper it's getting harder to block the manipulation of hidden Id's with tools like firebug, or forgetting to set an attribute on your property, will make it available in your view.

Although it's possible, maybe easy, to block some of those fields, but the more nested Domain/Data objects you have, the more trickier it will become to get this part right. And; what if you are "using" this domainmodel in multiple views? Will they behave the same? Also, bear in mind, that you might want to change your DomainModel for a reason that's not necessarily targeting the view. So with every change in your DomainModel you should be aware that it might affect the view(s) and the security aspects of the controller.

3) In ASP.NET MVC it is common to use validation attributes.

Do you really want your domain to contain metadata about your views? Or apply view-logic to your data-layer? Is your view-validation always the same as the domain-validation? Does it has the same fields (or are some of them a concatenation)? Does it have the same validation logic? Are you are using your domain-models cross application? etc.

I think it's clear this is not the route to take.

4) More

I can give you more scenario's but it's just a matter of taste to what's more appealing. I'll just hope at this point you'll get the point :) Nevertheless, I promised an illustration:

Now, for really dirty and quick-wins it will work, but I don't think you should want it.

It's just a little more effort to build a view-model, which usually is for 80+% similar to the domain model. This might feel like doing unnecessary mappings, but when the first conceptual difference arises, you'll find that it was worth the effort :)

So as an alternative, I propose the following setup for a general case:

• create a viewmodel
• create a domainmodel
• create a datamodel
• use a library like automapper to create mapping from one to the other (this will help to map Foo.FooProp to OtherFoo.FooProp)

The benefits are, e.g.; if you create an extra field in one of your database tables, it won't affect your view. It might hit your business layer or mappings, but there it will stop. Of course, most of the time you want to change your view as well, but in this case you don't need to. It therefore keeps the problem isolated in one part of your code.

Web API / data-layer / DTO

First a note: here's a nice article on how DTO (which is not a viewmodel), can be omitted in some scenario's - on which my pragmatic side fully agrees ;-)

Another concrete example of how this will work in a Web-API / ORM (EF) scenario:

Here it's more intuitive, especially when the consumer is a third party, it's unlikely your domain model matches the implementation of your consumer, therefore a viewmodel is more likely to be fully self-contained.

note: The name "domain model", is sometimes mixed with DTO or "Model"

Please note that in Web (or HTTP or REST) API; communications is often done by a data-transfer-object (DTO), which is the actual "thing" that's being exposed on the HTTP-endpoints.

So, where should we put these DTO's you might ask. Are they between domain model and view models? Well, yes; we have already seen that treating them as viewmodel would be hard since the consumer is likely to implement a customized view.

Would the DTO's be able to replace the domainmodels or do they have a reason to exists on their own? In general, the concept of separation would be applicable to the DTO's and domainmodels as well. But then again: you can ask yourself (,and this is where I tend to be a bit pragmatic,); is there enough logic within the domain to explicitly define a domainlayer? I think you'll find that if your service get smaller and smaller, the actual logic, which is part of the domainmodels, decreases as well and may be left out all together and you'll end up with:

EF/(ORM) Entities ↔ DTO/DomainModel ↔ Consumers

---

disclaimer / note

As @mrjoltcola stated: there is also component over-engineering to keep in mind. If none of the above applies, and the users/programmers can be trusted, you are good to go. But keep in mind that maintainability and re-usability will decrease due to the DomainModel/ViewModel mixing.

ASP.NET MVC, Model and ViewModel separation of concerns?

• Most of the times, ModelView objects are just containers holding Model objects when we need to send multiple types of them, or when we need to pass couple of more properties which are only needed in Views.
• If the View's job is to display the details of a Model and there is nothing else to pass to View, why not?
• Depends. You can use your ModelView and Model classes just to carry data between layers. And take care of validation via cutom model binders or with a service layer.
• There's no reason why they shouldn't know about ModelViews. But usually you just get the requested Model(s) from the service layer from the controller, and then pass it/them directly or in a ModelView to the View.

BTW, I wouldn't consider ModelViews as an architecture. It's more like "use one when you need one". After all, there's no point in doing this to pass data to view :

class SomeModelView {
    public MyModel model { get; set; }
}

Just pass the MyModel if that's enough for the view to do its job.

MVC 3 - Controllers and ViewModels - Which should contain most of the business logic?

For controllers and ViewModels, which should contain most of the business logic?

None of those.

I've tried a few ways to get my ViewModels to practically contain all the business logic. However, I do have to have an argument in my ViewModel's constructor that takes a Unit of Work. Is this a good idea?

imho It's a very bad idea. First of all you are breaking several of the SOLID principles. Bundling all code into the view model makes it hard to test. What if you want to use some of the business logic in another view? Do you duplicate that code?

What is the best practice here?

Let's go back to the MVC pattern first. It's a quite wide definition but knowing it should give you a feeling of what you should place where.

• The "Model" in MVC is really everything that is used to pull the data together. It can be webservices, a business layer, repositories etc.

• The view is all code that generates the HTML (since we are talking about web).

• The controller should be considered to be a glue between the model and the view. Hence it should take the information from the Model and transform it into something usable by the view.

The problem with that structure is that it's quite easy to "leak" layer specific information into the other parts of the pattern. Hence Microsoft introduced ViewModels into their implementation of MVC.

In this way we can remove all rendering logic from the views and put it into the ViewModel. Instead of doing this in your view:

<span>@(model.Age == 0 ? "n/a" : model.Age)</span>

you put that code inside the ViewModel instead and simply call @model.Age. In this way you don't have to duplicate that code in all views that are using your view model.

The answer to your question about the ViewModel is that it should only contain logic which is used to render the information from the "Model" properly.

As for the controller, I would not put any business logic into it either. First of all, it makes it very hard to test your logic. Then you add more responsibilities to it (and by doing so breaking SRP). The only logic that is valid in the controller is to take the information from the ViewModel and transform it into something usable by the "Model" and vice versa.

Hope that answers your question.

Update

I would create a separate project and add classes to it. Then just add a reference from your webproject and call those classes in the controllers.

I would also start using an inversion of control container to get those dependencies created for me automagically.

Autofac can both discover your services for you (zero-configuration) and inject itself into MVC.

To follow the separated interface pattern create the following projects:

• YourProject.BusinessLayer <-- Add your classes here
• YourProject.BusinessLayer.Specification <-- Add you interfaces that defines your business layer here.
• YourProject.Mvc <-- The MVC project.

The "Specification" project can be used to make it easier to test things and to make it easier to switch implementation (might be only a few classes and not necessarily the entire business layer). Read up on "Seperated Interface Pattern"

Should ViewModels be used in every single View using MVC?

It's not a requirement but it is a best practice.

You want to decouple your database from your presentation as much as possible and having a ViewModel (even if it is identical) gives you that seperation. It also keeps things consistent so you don't have some views with models and some without. This type of design makes you think about all the data you want your views to adhear to and figure out optimizations, see if duplication of data might be occurring, keep data considated to one location, etc.

Think of your ViewModel like a contract with the View.... this View requires X to work.

Little more work up front but it will pay off in the end.

MVVM pattern for WPF: Model vs ViewModel

If you want to keep a clean layer model, you should not include public Model model {get; set;} in your ViewModel.

So, for example, if you have a command, targeting some business model, your structure should be something like this:

//you don't have this one... but well, maybe other cases have
public class SomeService : ISomeService
{
    //member of ISomeService
    public void SomeFancyMethod(Model model)
    {
        //do stuff..
    }
}

public class Model //might be database, or domain model.
{
   public string Input { get; set; }
   public string Output { get; set; }
}

As for your viewmodel, it will become something like this:

public class ViewModel
{
    private ISomeService _someService;

    //note: someService is passed through a IoC service like ninject, unity, autofac etc.
    public ViewModel(ISomeService someService)
    {
        _someService = someService;
        //initialize the command:
        command = new RelayCommand(() =>
        {    
            _someService .SomeFancyMethod(new Model()
            {
                //properties could be mapped with an automapper.
            });
        });
    }

    public ICommand command {get; private set;}
    public string Input {get; set;}
    public string Output {get; set;}
 }

Note: there are some additional techniques involved:

• using an inversion of control container, and pass the service
  through the constructor.
• abstracting the service by means of an
  interface (ISomeService)
• possibly some automapper to isolate your mapping from and towards Models/ViewModels

---

"So why make this so 'complicated'? You are just making a copy.", a commonly heard argument against this pattern:

Well:

1. it isn't complicated
2. doing this will separate your layers. This mean that changes in your datalayer doesn't break your View. In the long run, you'll benefit, as change will come and you'll need to maintain the code.

How to create complex ViewModels in MVC ASP.NET

No man, the whole purpose of a view model is to model the exact data you need for a view, nothing more, nothing less. It's not really a security issue, I mean, if you were to be storing things like passwords and stuff in the viewmodel than your doing wrong on such a level I've never seen before. ViewModels main purpose in the mvc framework is to allow you to pack and unpack multiple models and extra properties in order for your user to be able complete whatever targeted action they need to complete without giving them the impression they are drinking from a firehouse. I guess it has some "security" standpoints as you don't need to pass full models but just because something is included in the view model doesn't mean that you have to actively output HTML for that property. Most of those actions should occur server side anyway or in razor checks that generate the HTML.

If you are overlyconcerned about security and your controllers then you should look into 3 tier architecture anyway.

---

Related Topics