This article is taken from the book ASP.NET MVC 2 in Action. The authors discuss designing a model to represent the data coming into an application. ASP.NET MVC 2 features coupled with a strong input model make it easy to work with user input in an application.


A model is a representation of something meaningful. It is not necessarily something physical, but something real:a business concept or an API that’s difficult to work with.

When we write object-oriented software, we create classes that make up this representation. We can create our representation so that when we use it we are working in our natural human language, like English or Spanish, or business jargon, instead of in mere programming language constructs like booleans, meaningless strings, and integers. When working with a UI framework like ASP.NET MVC, the UI is the complex problem that we manage. It’s the data in a window, a form submission from a user, the options in a select list. While model is an overloaded term in software, we’ll be talking about the presentation model, the model that represents the screen and user input from the screen of an application. More specifically, we will focus on representing user input.

Just like a presentation model represents a display, we craft a model to represent the data coming into our application. And just like a strong presentation model makes it easy to work with our data in the view, a strong input model makes it easy to work with user input in our application. Instead of working with error-prone string
keys and inspecting request values that hopefully match input element names, we can leverage ASP.NET MVC 2 features to work with a strong input model.

Designing the Model:

This simple form has two text boxes and a check box.
For Source Code, Sample Chapters, the Author Forum and other resources, go to

As a feature of our application, it’s also worthy of a formal, codified representation—a class. Designing the class to represent this form is easy: it’s two strings and a boolean value. The input model in listing 1 is a simple class with a focused job.

#1 A property represents a textbox
#2 Represents input in second textbox
#3 Represents the checkbox

It is the surface area of user input--nothing more, nothing less.

Presenting the Input Model in a View:

Views can be configured with the input model as the ViewData.Model type. We craft the HTML form using the input model. ASP.NET MVC 2 ships with several helpers that ease this and allow for strong associations between form element names and model property names.

For Source Code, Sample Chapters, the Author Forum and other resources, go to

#1 Again, specifying the model
#2 A helper for the label
#3 A helper for textboxes
#4 A helper for checkboxes

Note the special HTML Helpers that take a lambda parameter (#2). These helpers render HTML form elements with the name attribute set to the name of the property expressed in the lambda. When working with HTML forms, work must be done to ensure that the software is looking for values in the known location.

Lambda expressions aid in refactoring Don’t underestimate the value of lambda expressions in your views. These are compiled along with the rest of your code, so if you rename an action, for example, this code will break at compile time. Contrast this with code in your ASPX that references classes and methods with strings. You won’t find those errors until runtime. Having strongly typed view data references also aids in refactoring. Using a tool like JetBrains ReSharper ( will allow you to refactor code and have it reach out to all of the views that use it as well. Very powerful, indeed.

Before strongly-typed helpers, we relied on magic strings and there was effort to ensure consistency between the input form and the processing logic. With strongly-typed helpers like we use in listing 2, ASP.NET MVC 2 handles this coordination for the developer, so renaming a property won’t cause our screen to malfunction.

Working with the Submitted Input:

The form in listing 2 posts to the Save action, and ASP.NET MVC 2 offers a convenient way to translate the values in the HTTP request to our model. This process is called model binding, and we’ll take a quick look at it now in listing 3.

Listing 3 Model binding form values to the input model

By declaring the action’s parameter as a NewCustomerInput object, the value is wired-up by ASP.NET MVC 2’s DefaultModelBinder and delivered properly (#1). This is the default behavior in ASP.NET MVC 2. Our action works with our strong input model object and not a dictionary of key value pairs (#2). In this case, it’s not doing much; we’re just sending it as the model of a different view, so in the example we can inspect the saved values. But, in a real action, we’d have the opportunity to work with it as with any other class—persist it or pass it along to collaborating classes for further processing. Many views are not just displays or input forms but combine elements of both to achieve a rich user experience. For Source Code, Sample Chapters, the Author Forum and other resources, go to


By representing user input with an explicit model object, we can use ASP.NET MVC 2 model binding to work with objects. With strong presentation models comes an avalanche of simplicity that enables maintainability and rapid construction. Refactoring, renaming, adding fields, and changing behaviors have returned to the world of programming. Freed from the shackles of the designer and a constant effort to maintain consistency across a myriad of magic strings that may or may not make sense, developers can focus on one thing at a time. The model is at the core of Model-View-Controller.

For Source Code, Sample Chapters, the Author Forum and other resources, go to