March 2, 2021
Hot Topics:


  • By Jani Järvinen
  • Send Email »
  • More Articles »

Instead, in ASP.NET MVC applications you have a separate .aspx page, which is the view (see Figure 4). However, the controller often needs to specify what data to display on the view, such as choosing the correct product. To better enable this communication between the view and the controller, the ASP.NET MVC framework contains a class called ViewData. This is a dictionary of name and value pairs, and it is accessible from both the controller class and the view's .aspx page.

Figure 4: Adding views is easy with the Add View extension command.

Here is an example of a definition of the HomeController's Index action:

public ActionResult Index()
   ViewData["Title"]   = "Home Page";
   ViewData["Message"] = "Welcome to ASP.NET MVC!";
   return View();

The Index method uses the ViewData object two times, to set a "Title" and a "Message". Because the ViewData is a collection object, you can freely choose any unique string value you prefer. The third statement in the method returns a View object, about which you will learn more soon.

In the meantime, see how the values set to the ViewData can be used from the view page. By default, a view is implemented using a regular .aspx page, whose name corresponds to the name of the action currently being served.

For instance, the preceding Index method on the controller class would correspond to the view implemented by the Index.aspx file. All views are stored in the Views folder in the solution, each in their own sub-folder matching the name of the controller. For instance, the Index.aspx file for the Home controller's Index action would be stored in Views/Home/Index.aspx inside the solution. It is important to store the views in correct folders; otherwise, they cannot be found.

Here is the implementation of the Index.aspx file of the Home action:

<%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master"
    AutoEventWireup="true" CodeBehind="Index.aspx.cs"
    Inherits="MvcApplication1.Views.Home.Index" %>
<asp:Content ID="indexContent"
   ContentPlaceHolderID="MainContent" runat="server">
      <h2><%= Html.Encode(ViewData["Message"]) %></h2>
         To learn more about ASP.NET MVC visit
         <a href="http://asp.net/mvc"
            title="ASP.NET MVC Website">http://asp.net/mvc</a>.

In this code listing, you can find a reference to the ViewData object inside the "h2" tags. When the "Message" value has been set in the controller, the same value can be used in the .aspx page (the reference to the "Title" value appears in the Site.master file). Note how the Html.Encoding helper method is used to properly encode the string to valid HTML; it might well be that the string stored in the ViewData dictionary contains special characters which would require encoding.

The Html member is a property on both regular ASP.NET MVC pages (descending from the class System.Web.Mvc.ViewPage) and MVC master pages (descending from System.Web.Mvc.ViewMasterPage). It points to a class named HtmlHelper, also in the System.Web.Mvc namespace.

By using the ViewData object, you can transfer everything you need easily from the controller to the view. However, although you can use the ViewData object, it is not always the best available option. Next, you will learn how to bring a model to the equation.

Using Models Effectively

So far, you have seen how you can move data from a controller method to an appropriate view page by using the ViewData object. Although this is easy to do, oftentimes you will find yourself repetitively copying values from a given object to the ViewData object just to be able to show them in the view. Could there be an easier way?

Luckily, there is. By using a model class, you can specify that a view should directly understand the properties of the model class; this means you do not need to use the ViewData object nearly as often. For instance, following the previous example of product data, you might have a class like this to represent product information:

public class Product
   public int Id                    { get; set; }
   public string Name               { get; set; }
   public string Description        { get; set; }
   public float ListPrice           { get; set; }
   public float CostPrice           { get; set; }
   public string WebPage            { get; set; }
   public string SystemRequirements { get; set; }

This Product class has public properties for each value that a fictional product would need. Then, your application could have a database in which the products are stored, and you might use, for example, LINQ to SQL classes to read that data from the database into Product objects.

If you wanted to show product information on a view, you could, of course, copy each property value in the Product class to the ViewData object, and then use that object in the .aspx code. Although this works, this is tedious, especially for objects that have dozens of properties.

You can lessen your work considerably by specifying the Product class as the model for your view page. This way, you can directly access the properties of the specified model class, giving you also strong typing and IntelliSense support.

Page 3 of 4

This article was originally published on December 3, 2008

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date