The ASP.NET MVC framework (which I will refer to as "MVC" in this article) encourages developers to work closer to actual rendered HTML than does the more traditional web forms ASP.NET framework. The web form framework abstracted away much of the HTML, allowing developers to create sophisticated web pages simply by dragging controls onto a design surface. In fact, with the web forms framework, it is sometimes possible for someone with no knowledge of HTML to build an entire web application.

But MVC’s view engine removes that abstraction, encouraging users to write more of their own HTML. By doing so, developers also get more control over what is rendered to the client.

Some web developers may be surprised to learn that most of the server controls they are used to dragging onto a design surface do not work in MVC. This is because ASP.NET server controls are self-contained objects that encapsulate all their functionality, including the C# or VB code they run. This is contrary to the way that MVC works. In the MVC framework, all business logic code is in either the model (if it applies to the data) or in the controller if it applies to routing or output.

An MVC view consists only of an ASPX page. By default it doesn't even contain a code-behind file.

Let’s analyze a typical MVC view. Like a web form, an MVC view contains a page directive at the top.

<%@ Page Title="Sports" Language="C#" 
MasterPageFile="~/Views/Shared/Site.Master" 
Inherits="System.Web.Mvc.ViewPage>
%>

The Title, Language and MasterPageFile attributes should be familiar to anyone who has developed in ASP.NET. The meanings of these attributes have not changed in MVC. The Inherits attribute is also used in web forms development, but in this case, we are inheriting from a ViewPage that contains our model.  The model represents the data we wish to render (I will write more about the MVC model in a future article.) By inheriting from a ViewPage, we provide the model data directly to the page and we can strongly type the keyword Model to whatever data type our model is.

Mixed in with the HTML of our page, we can output some server side data by enclosing it in <% %> tags.

If you wrote any web sites with classic ASP (the predecessor to ASP.NET), you probably used these tags. (I recently heard someone refer to them as "bee stingers").  If you place "=" in front of a value or variable, the view engine will output the value or contents of that variable. For example

<%=System.DateTime.Now %>

outputs the current date and time, like the following

10/2/2009 6:08:46 PM

We mentioned earlier that the Model keyword is strongly-typed. For example, If we inherit our ASPX from  System.Web.Mvc.ViewPage, then our model represents a Customer object and we can output a property of that model class.

Assuming that our Model is uses the following Customer class:

public class Customer
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

, we can output the FirstName property with the following markup:

<%= Model.FirstName %> 

You probably already know that it is almost always a bad idea to output text directly for the screen without encoding it, as I did above. Failure to do so may leave your site open to scripting attacks. Fortunately MVC includes an Encode helper method to encode strings for safer output. That helper method (along with other helpers) is available via the Html property of the ViewPage from which our view inherits. We can call the helper method and encode the first name with the following markup.

<%= Html.Encode(Model.FirstName) %>

This outputs the FirstName property, but encodes it to prevent problems if the first name property somehow gets infected with some client-side script.

Other helper methods of the ViewPage give you the ability to begin and end an HTML form, to render an HTML textbox, to render a hidden field, to render an HTML listbox, and perform many other useful functions.

The code below will output a hyperlink with the text "Home" that links to the Index method in the Home controller.

<%= Html.ActionLink("Home", "Index", "Home")%>

Another way to use data in the view is to store it in ViewData. ViewData is a property of the view and contains a dictionary of name/value pairs. You can add a value to this dictionary in the controller with code like the following

ViewData["Greetings"] = "Hello dummy";

and display a ViewData element in the view with markup like the following

<%= Html.Encode(ViewData["Greetings"]) %>

Below is the full markup for a sample MVC view page

<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage" %>
"Content1" ContentPlaceHolderID="TitleContent" runat="server">
Index


"Content2" ContentPlaceHolderID="MainContent" runat="server">

<%= Html.Encode(ViewData["Greetings"]) %>


<%= Html.Encode(Model.FirstName) %>
<%= Html.Encode(Model.LastName) %>    


<%= Html.ActionLink("Home", "Index", "Home")%>

Here is the output of the view page above

If you don’t like the view engine that ships with MVC, it is possible to replace it with your own. Some open source projects, such as Spark have already given users this ability.

Using the MVC view engine encourages developers to have more control over the output sent to the client and provides a greater separation of concerns for the application as a whole.

Download the code for this sample at MVCDemoView.zip (281.64 KB)