The “magic” takes place in the form of a ModelBinder. ModelBinders are responsible for the fairly common task of converting between a collection of Form values and a strongly typed Model class that should be created from these values. First, let’s look at the equivalent code that doesn’t use a ModelBinder. If I wanted to create my customer object more explicitly in the controller, I could do it like this:

[AcceptVerbs(HttpVerbs.Post)]
<span style="color: #0000ff">public</span> ActionResult Create(FormCollection formValues)
{
  var customer = <span style="color: #0000ff">new</span> Customer();
  customer.FirstName = Request.Form[<span style="color: #006080">&quot;FirstName&quot;</span>];
  customer.LastName = Request.Form[<span style="color: #006080">&quot;LastName&quot;</span>];
}

This gets old fast. A better method that is one step closer to the ModelBinder approach would be:

[AcceptVerbs(HttpVerbs.Post)]
<span style="color: #0000ff">public</span> ActionResult Create(FormCollection formValues)
{
  var customer = <span style="color: #0000ff">new</span> Customer();
  UpdateModel(customer);
}

This helper method automatically updates the properties of the object we pass into it with the values from incoming form parameters (using reflection to match up the property names with the form names). If we want to avoid dealing directly with the FormCollection in our controller, we can simply use the original signature I showed above, and have the controller take in as its parameter the model object (Customer in this case) that we want to have populated from the form.

If there are problems with the population of the model object, the ModelState.IsValid property will be false, and the ModelState will include details about the rule violations (such as a type mismatch). You can find more detail on this here.

Does the Model used for a controller that handles a POST need to be serializable?

No, it simply needs to have properties that can be mapped to the fields coming in from the POST. The class itself is never serialized or deserialized or sent over the wire. It’s simply mapped from the POSTed fields by a ModelBinder.

What if I need to bind custom types to my Model class?

In this case, you’ll want to write your own ModelBinder and register it so that ASP.NET MVC knows to use it when faced with a given type in your application. Writing a ModelBinder simply requires that you inherit from DefaultModelBinder and override the ConvertType() method. In order to register your type with its custom ModelBinder, you would do this:

<span style="color: #008000">// In Global.asax Application Start or an HttpModule</span>
ModelBinders.Binders.Add(<span style="color: #0000ff">typeof</span>(Customer), <span style="color: #0000ff">new</span> CustomerBinder());

Here is agood example of writing a custom ModelBinder class.

Doesn’t having the Model referenced in the View eliminate the need for the Controller?

In response to seeing code in the View like this:

<%= ViewData.Model.FirstName %>

Someone asked if this was stepping on the responsibilities of the Controller, since the View was talking directly to the Model. Here there can be differing opinions. It’s not strictly required that you pass your Model classes to the View. You can simply pass in collections of strings via ViewData. Another common approach is to use a DTO(Data Transfer Object) or ViewModel (the “VM” in the MVVM palindrome pattern) which typically is a subset of one or more Model classes in your application that contains only the information necessary for a given View. It’s also not uncommon to pass your Model into the View. It’s a matter of preference and there are pros and cons to these approaches.

What is not recommended is for your Model (the Customer in my example here, which has a FirstName property) to be persistence aware and to magically go and fetch itself from the database when it is referenced by the View. The above code should only work if the Controller has explicitly passed in the Model to the View, using code like this:

<span style="color: #0000ff">public</span> <span style="color: #0000ff">void</span> View(<span style="color: #0000ff">int</span> id)
{
  Customer customer = customerRepository.GetCustomer(id);
  <span style="color: #0000ff">return</span> View(customer);
}

It is still the responsibility of the Controller to pass in whatever data the view needs. The view should not have this responsibility. Nor should the model know how to persist itself. This separation of concerns ensures loose coupling, testability, and a more flexible design.

An example of using a ViewModel/DTO would be something like this:

<span style="color: #0000ff">public</span> <span style="color: #0000ff">class</span> CustomerSummaryViewModel
{
  <span style="color: #0000ff">public</span> <span style="color: #0000ff">string</span> FirstName { get; set; }
  <span style="color: #0000ff">public</span> <span style="color: #0000ff">string</span> LastName { get; set; }
  <span style="color: #0000ff">public</span> DateTime DateOfLastPurchase { get; set; }
  publi DateTiem AmountOfLastPurchase { get; set; }
}
...
<span style="color: #0000ff">public</span> <span style="color: #0000ff">void</span> Summary(<span style="color: #0000ff">int</span> id)
{
  Customer customer = customerRepository.GetCustomer(id);
  Order order = orderRepository.List(id).Take(1); <span style="color: #008000">// gets most recent order</span>
  var summary = <span style="color: #0000ff">new</span> CustomerSummaryViewModel() {
    FirstName = customer.FirstName,
    LastName = customer.LastName,
    DateOfLastPurchase = order.DatePurchased,
    AmountOfLastPurchase = order.Amount };
&#160;
  <span style="color: #0000ff">return</span> View(summary);
}

Using this approach, the View will have access only to the exact pieces of data that it requires, and no more. If you want to ensure that the View never calls methods on your Model objects or you want to verify with tests that your View is receiving exactly the data that it needs, then using this ViewModel/DTO approach can be valuable.