Question

With MVC3, should I design my view models such that there is one that is bound to the view (DisplayModel), and one that is posted back to the controller (EditModel)?

To clarify, I am not asking about data models vs. view models — I know it’s not good to bind my views/controllers to data/domain models.

Nor am I asking about sharing one model across two separate views, one view that is used for displaying the data, and another view that is used for editing the data.

Rather, I am asking about one view that is used for editing data, and the model that is bound to the view vs. the model that is bound to the controller action.

In other words, if this is my view:

@model MyApp.Models.CustomerModel

Should my controller action look like:

public ActionResult Index(CustomerModel model)

Or:

public ActionResult Index(CustomerEditModel model)

At one point, we were doing the latter (separate). But lately, we’ve started doing the former (shared).

The reason for this change was because:

1. With MVC3 unobtrusive validation, if I’m using DataAnnotations on my model for validation, this is needed in both models if they are separated (on the display model to map client-side validation, and on the edit model for server-side validation).

2. As our application matured, we realized that our display and edit models were 95% identical, with the exception of the select lists that were in our view models. We’ve now moved these to a shared class and are passing these in via the view now.

But I’ve seen some other discussions that point to having shared models for view/controller to be a bad idea, and that it violates separation of concerns.

Can someone help me understand the tradeoffs for these two approaches?

Answer 1

I’ve seen perfectly good arguments for and against, it just depends what works best for your application. There’s no one size fits all approach that can be applied!

If you haven’t read it Jimmy Bogard has written a very good post about how his team does MVC here, which covers this topic.