Introduction

In ASP.NET web forms and MVC, the UI goes through a rendering process. In web forms, the Page class uses a rendering process to translate a control hierarchy into HTML content for the browser. The code-behind file exposes properties and methods that affect the control's state, and the final representation of each control is what gets rendered to the browser. The page lifecycle also affects this process.

ASP.NET MVC changes this process fundamentally. Rather than dealing with a control hierarchy, MVC views render directly in a top-to-bottom fashion, similar to how ASP used to work. The core difference between ASP and ASP.NET MVC is that the business logic is separate from the view, and is not intertwined. Each view also has a model, a property directly accessible called "Model" that contains the data returned from the controller, as a way to directly reference the data specific to that view. You will see me refer to models within this article, and every reference to it refers to this process.

The way to construct a user interface can be a big change to most developers. For instance, in web forms, if you wanted to programmably add a style sheet to the HEAD element, a developer can put code to do this in the Load event handler. But in MVC, a style sheet can only be injected into the view at the time the HEAD element is being rendered; it can't be referenced directly as an object.

Creating the UI

A UI still uses similar constructs to web forms. It has a @Page directive with the same settings (though the code-behind reference points to a standard ASP.NET MVC class). It still uses markup and mixes in server-side code. But to make the entire server-side process easier, rather than using controls, MVC uses the HtmlHelper class. What used to be a control is now a method of the HtmlHelper class. For instance, to render a textbox in the browser, instead of using a control, a textbox can be written using the following code.

<%= Html.TextBox(“Control”).ToHtmlString() %>

This statement renders an <input type="text"> element directly to the response stream. Note that the ToHtmlString method call; this is a new breaking change in ASP.NET MVC 2 as each helper returns this instead of a string directly. However, you can omit this if you like, and the code will work the same (the method will be called implicitly).

The following is a sample UI using these helpers:

Listing 1: Sample Form using MVC

Each one of these methods returns a string that represents the HTML of the control. Using these methods allows for the in-built features of MVC to work, as MVC uses certain schemes to link features together. You can certainly define the HTML for the control directly, if you like.

New “For” Suffix Helpers

With MVC 2 comes a whole new group of methods suffixed with "For", such as TextBoxFor, CheckBoxFor, etc. These methods use a lambda to select the property within the model to use to display the UI. For instance, Html.TextBoxFor(i => i.FirstName) extracts the value of the first name of the model.

Listing 2: Using For Extension Methods

This does two things: the first is it renders the underlying HTML element with the model's intrinsic value. Additionally, the ID and name of the element use the text from the lambda expression supplied here as the name (ScenarioNumber and Description in this example). These methods can make it very convenient to render content directly to the model, and also help to hook up model binding (explained later).

Data Annotations

I mentioned these new methods for rendering content extract its value from the data model. The reality is that it does more than this. By using a lambda, the ASP.NET MVC framework also looks for any data annotations on a property. A data annotation is an attribute that you specify on the model. These annotations control how the helper methods work in various ways. For instance, take a look at the following sample property:

Listing 3: Data Annotation Support

So here, our model class has a BoolValue property with two annotations, the latter one for validation (a subject of a future article), and the former one for storing the display name of the field. The display name attribute comes in handy if you want to use the next extension method to write out a <label> element for this property as in:

Listing 4: Rendering the Label

This renders a label element with our "Boolean Val" name, followed by a checkbox with the model value name.

A Final Model Binding Example

It's best to just look at an example of the entire process and the process of how model binding works. Let's walk through a sample setup form using these constructs. To start, we must have a controller that points to our view. Below is a sample view that has a method to return the view by referencing a URL of SampleForm/ForIndex. The next action method responds to a form post only.

Listing 5: Sample Controller

This controller is simple enough; primarily, keep an eye on the initial values entered. The model used for the ForIndex view is the SampleFormTestClass that contains some data annotations; a lot of the data annotations tend to be validation-specific, a topic too big for this article.

Listing 6: Sample Model

The UI uses the properties within this model using the following form example. I'm going to break it up into pieces. The first piece is the definition of the form; forms can be specified using one of the syntaxes below.

Listing 7: Defining a Form

Everything within the form tags is posted back to the server to our ForIndex action method marked with a [HttpPost] attribute. The first to render is a label and checkbox combination for our BoolValue property. Remember that it had a DisplayName attribute, which renders the text "Boolean Val" for the label, instead of the actual property name (by default).

Listing 8: Setting Up a Label and CheckBox

Alternatively, if you like radio buttons for yes/no fields, the following is also an option. While no radiobuttonlist control exists, each radio button can map to a boolean or other type property (here a string) to render the radio button list. The second parameter is not the text of the radio button; actually, it's the value to match to actually select the item in the list (its associated value). The second radio button is selected since the model has a no value.

Listing 9: Setting Up a Radio Button List

We covered rendering textboxes and text areas to the screen; additionally below is a hidden field and a password box. A word of caution with these controls; if you have a specialized data type (like a DateTime or an integer) that is being represented by a text box, there isn't any implicit error checking for these types of data values. Validation can be applied to the value to prevent this; if for some reason an invalid value slips through, the value is omitted and the default value is used (a default date of 1/1/0001, for example).

Listing 10: Setting Up Text Elements

The standard list types are also supported; below are methods to render a drop down list and list box using a list of data (can be static or data bound), and extracting the underlying value to supply as the default selected item. This may be a typical operation to occur within the controller, rather than the UI, but I put it in the UI for the example's sake.

Listing 11: Setting Up Lists

Not every HTML element has an associated HTML helper method. For instance, any type of button does not have a ButtonFor method. No support for linkbuttons exist too, which is a substantial change (because internally of the way that the MVC framework differs from web forms).

The final UI looks like the following:

Figure 1: The Sample Form

I tweaked the original values toggling the AltBoolValue and BoolValue ui controls, changing the combo selection, and creating an invalid date, which led to the following values being posted back.

Figure 2: The Posted Values

Here is the greatest feature about the model binding process; by using our lambda expressions, the values posted back within the form automatically get mapped to the class's properties, when the class is the parameter of the action method. So, since the fields posting back are related to our model class, MVC automatically supplied these form values to our object, and I don't have to manually perform this task. This process is customizable by creating a custom model binder if you like, but that is a subject for another day too.

If you don't like using the object reference directly in this way, and want more control over the process, the alternative is to specify a FormCollection collection as the parameter of the action method, which contains all of the form values within the form that posted back (and any other form related value that may come over too). This way, you can have more control over the data. The UpdateModel or TryUpdateModel methods can be used to apply the form collection to a model object too, as an added convenience.

Conclusion

ASP.NET MVC is powerful. Once you understand the building blocks mentioned in this article, you can begin to create complex UI's. The key is understanding how MVC takes away the control lifecycle/API/hierarchy architecture and uses an inline rendering approach, as well as understanding the separation of logic that MVC utilizes.

We looked at a variety of HTML helper methods used to construct UI's and make the UI construction process easier, as well as alternative ways we can pass this information around. MVC can take a form's values and apply them directly to an object. It's good to understand the basics before you jump right into building a complex UI, as building complex UI's need care and well-thought-out planning. We will be examining this in future articles.

About Brian Mains

Brian Mains is an application developer consultant with Computer Aid Inc. He formerly worked with the Department of Public Welfare. In both places of business, he developed both windows and web applications, small and large, using the latest .NET technologies. In addition, he had spent many hou... This author has published 73 articles on DotNetSlackers. View other articles or the complete profile here.