In MVC3, should I have separate "edit" models vs. "display" models?

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.

Answer 2

I agree with rich.okelly's answer that there's no right approach.

There are a couple of concerns I have with using one model, though.

It's going to be very to always use one model without having unneeded properties when the view needs to display a selectable list of objects. The model will need to have the list of objects as well as a property to accept the POSTed value the user chooses. These unneeded properties add a small amount of code clutter and overhead. (One way around this is to have the model contain only selected ID and have HTML helpers to build the lists.)

Another concern is more related to security. A common scenario is displaying information in a form that should be considered read-only. In the case of a ViewModel and an EditModel, the EditModel will only contain properties that are expected to be POSTed, whereas the ViewModel will contain all of the properties. For example, if a form displays a user's salary, a user will be able to POST a 'salary' and have it bound to the ViewModel's Salary property automatically by MVC. At this point, something has to be done to ensure it doesn't end up in the database. It could be if/else logic, a Bind attribute, Automapper logic or something else, but the point is that it's a step that could be overlooked. When considering the lifespan of an application, I like the explicitness of the EditModel over time.

These concerns don't mean that two models are good and one model is bad, but they should be considered when choosing a design.