Take the 2-minute tour ×

Is it a better idea to have a single ViewModel per view or one per controller action?


public ProjectController : Controller
    public ActionResult Edit(int id)
        var project = ...;

        return View(new ProjectEditViewModel(project));

    public ActionResult Edit(ProjectEditViewModel model)


    public ActionResult Edit(Project model)

    public ActionResult Edit(ProjectEditPostViewModel model)

Here are the three options, which is best?

  1. Use the same ViewModel for my POST/GET actions.
  2. Use a ViewModel for my GET action and my domain model for my POST action.
  3. Use a different ViewModel for GET and a different ViewModel for POST.
share|improve this question

3 Answers 3

up vote 9 down vote accepted

Using a different view model for the GET and POST actions is the best and most flexible design. But using the same view model for the GET and POST actions also works in 90% of the cases and it is fine a good design. So if using the same view model works in your scenario don't hesitate to reuse it like this.

In the case where different view models are used for the GET and POST actions there is still some relation between those classes: inheritance or composition.

share|improve this answer
In general is it a bad idea to use your Domain model itself as the object that you are POSTing to your controller actions? In my example, if my Project class is an Entity Framework class, is it a bad idea to use that as the parameter of my POST controller action? –  Dismissile Sep 13 '11 at 19:57
@Dismissile, very bad idea. Never use any domain model as input/output of any controller action and this under any circumstances. While there could be different opinions about the two approaches discussed here with view models, domain models are not even something that should ever be considered. You should always define view models, always. –  Darin Dimitrov Sep 13 '11 at 19:58
Thanks for the input. –  Dismissile Sep 13 '11 at 20:04
Similar to what you said about never using a domain model as input/output of any controller action. If I created a ViewModel for Editing a Project and named it ProjectEditViewModel, would that ViewModel have a reference to a Project as one of its properties or would you create a ViewModel with all of the fields that need to be displayed and then use some sort of Mapping to get the fields from the Project to the ViewModel? –  Dismissile Sep 13 '11 at 20:07
@Dismissile, I wouldn't reference any domain model as a property to a view model. I would include and repeat the properties I need in this particular view. –  Darin Dimitrov Sep 13 '11 at 20:08

The correct answer

Neither. There's no silver bullet and shouldn't be.

The correct answer is therefore: use as many view models as your user interface process demands. That's regardless of views or controller actions.

Sometimes an action demands a view, other a view. But don't follow some strict guidelines that would hinder your development. View models will come naturally as you develop your application. And should. Otherwise you may end up with unreasonable views that are based on some guideline you've set in stone.

This is actually a similar answer as @DarinDimitrov's, but with a direct conclusion.

share|improve this answer

Use different model to receive input parameters in Post action (I don't even call it ViewModel in that case) than to pass output parameters to the view.

That way you can customize exactly what input parameters do you accept.

share|improve this answer

Your Answer


