Take the 2-minute tour ×

I am wondering if it is a good idea or bad, placing things like a List of countries in ViewModel, for binding to a drop down list? For example on a site's Registration page.

I was under the impression that a ViewModel is supposed to represent an instance of the filled out form, but I think I may be wrong as I have seen other people put things like lists in their ViewModel.

Would it not be better to put it in a static class somewhere and called directly from the View?

Like CommonData.ListCountries(); and then using Lambda to convert to SelectList item list in the view Directly?

share|improve this question
add comment

2 Answers

up vote 7 down vote accepted

As you've realized there are a variety of ways to accomplish your goal. While the MVC design pattern encourages certain application organizations how you organize your models, views and controllers is ultimately a matter of preference.

Scott Allen discusses his preference for dealing with ASP.NET MVC drop down lists in a blog post. Scott uses an extension method to convert an enumerable of a complex type into an IEnumerable<SelectListItem> on his model. He then describes that upon post back ASP.NET MVC will not be returning the IEnumerable<SelectListItem> he sent to the view, but only the value the user selected. He then suggests that utilizing two models can simplify things.

This is a reasonable description of what I refer to as ViewModels and FormModels. A ViewModel carries the display data to the view and a FormModel is used for carrying collected data back to a controller action. To explain further:

  • ViewModels contain data that help render views. By organizing my ViewModels this way I can place all necessary information to render a particular view into an associated model. This prevents me from having to use ViewData for anything that's not truly temporary.
  • FormModels are used to gather user input. FormModels (almost) never contain references to other complex types and are made up of primitives, DateTimes, and strings.

In either case I have a hard rule to never reuse a model for a different view. Having your models closely aligned with the views used to render them makes your views easier to write. You don't have to worry about things like static methods because your models should be carrying data to their associated views in a form that is easy for them to render. Tools like AutoMapper can help "flatten" domain objects into models for display purposes.

For additional reading checkout: ASP.NET MVC terminology is tripping me up - why 'ViewModel'?

share|improve this answer
Thanks for the explanation. But, if i am not using AJAX what is the cleanest way of showing errors on the form and re-binding the drop down lists? I can't really create a new instance of my view model because it contains a partially filled form, but I still need to re-create the list of countries to pass back to the view the second time. –  lahsrah Oct 31 '10 at 21:32
add comment

Whatever data your View needs, put it in the ViewModel.

The way i see it, once your view is going through the rendering process, it should have all the info it needs from the Model it is bound to.

If you start to use helper methods, then the View is "going back to the controller" in a sense. Extension/helper methods are fine for formatting, etc, but they should not call through the model.

Don't forget, you also have ViewData (basically HttpContext.Current.Items, lives for single request), which is a lightweight storage mechanism that can be used to share data across partial views (for example).

share|improve this answer
ok, so how do i handle the case where there are validation errors in the form and the ViewModel needs to be passed back into the original action to display the parially filled form, I would need to fetch the List again from the database. In that is it a good idea to add a Populate method on the view model to re-populate these drop down lists before passing it back to the view so i am not populating dropdown lists in two places? –  lahsrah Oct 29 '10 at 4:36
No, that is not a good idea. ViewModel's should be simple storage mechanisms to hold onto data, not retrieve it. It should have nothing but properties (generally speaking). Remember, this is not Web Forms. There is no ViewState, your requests should be stateless. If after you submit your form you need some data again, go get it again, and just set the value into the ViewModel. Validation errors should be handled by model state. Take a look at some of the vids/tutorials on www.asp.net/mvc –  RPM1984 Oct 29 '10 at 4:58
Even better than refetching the data is doing AJAX form posts and letting the client (eg Javascript) decide where to redirect the page after a success or error message is returned. –  Ryan Oct 29 '10 at 5:04
@Ryan - absolutely. Just don't "call back to a helper method". –  RPM1984 Oct 29 '10 at 5:15
add comment

Your Answer


