Specifying a View

In the previous section, you looked at examples of what goes inside a view. In this section, you look at how to specify the view that should render the output for a specific action. It turns out that this is very easy when you follow the conventions implicit in the ASP.NET MVC Framework.

When you create a new project template, you'll notice that the project contains a Views directory structured in a very specific manner (see Figure 3.1).

By convention, the Views directory contains a folder per controller, with the same name as the controller, but without the Controller suffix. Thus, for the HomeController, there's a folder in the views directory named Home.

Within each controller folder, there's a view file for each action method, named the same as the action method. This provides the basis for how views are associated to an action method. For example, an action method can return a ViewResult via the View method, as follows:

public class HomeController : Controller {
    public ActionResult Index() {
        ViewBag.Message = "Modify this template to jump-start 
                           your ASP.NET MVC application.";
        return View();
    }
}

This method ought to look familiar; it's the Index action method of HomeController in the default project template.

Notice that unlike the sample in Code Listing 3-2, this controller action doesn't specify the view name. When the view name isn't specified, the ViewResult returned by the action method applies a convention to locate the view. It first looks for a view with the same name as the action within the /Views/ControllerName directory (the controller name without the Controller suffix in this case). The view selected in this case would be /Views/Home/Index.cshtml.

As with most things in ASP.NET MVC, this convention can be overridden. Suppose that you want the Index action to render a different view. You could supply a different view name, as follows:

public ActionResult Index() {
   ViewBag.Message = "Modify this template to jump-start 
                           your ASP.NET MVC application.";
   return View("NotIndex");
}

In this case, it will still look in the /Views/Home directory, but choose NotIndex.cshtml as the view. In some situations, you might even want to specify a view in a completely different directory structure. You can use the tilde syntax to provide the full path to the view, as follows:

public ActionResult Index() {
   ViewBag.Message = "Modify this template to jump-start 
                           your ASP.NET MVC application.";
   return View("∼/Views/Example/Index.cshtml");
}

When using the tilde syntax, you must supply the file extension of the view because this bypasses the view engine's internal lookup mechanism for finding views.

ViewData and ViewBag

The preceding example used a ViewBag.Message property to pass information from the controller to the view above. Let's look at that in more detail.

Technically, data is passed from the controllers to the views via a ViewDataDictionary (a specialized dictionary class) called ViewData. You can set and read values using standard dictionary syntax, as follows:

ViewData["CurrentTime"] = DateTime.Now;

Although this continues to be available, ASP.NET MVC 3 leveraged the C# 4 dynamic keyword to allow for a simpler syntax. The ViewBag is a dynamic wrapper around ViewData. It allows you to set values as follows:

ViewBag.CurrentTime = DateTime.Now;

Thus, ViewBag.CurrentTime is equivalent to ViewData[CurrentTime].

For the most part, there isn't a real technical advantage to choosing one syntax over the other. ViewBag is just syntactic sugar that some people prefer over the dictionary syntax.


Note
Although there might not be a technical advantage to choosing one format over the other, there are some critical differences to be aware of between the two syntaxes.
One obvious difference is that ViewBag works only when the key being accessed is a valid C# identifier. For example, if you place a value in ViewData[Key With Spaces], you can't access that value using ViewBag because the code won't compile.
Another key issue to be aware of is that dynamic values cannot be passed in as parameters to extension methods. The C# compiler must know the real type of every parameter at compile time in order for it to choose the correct extension method.
If any parameter is dynamic, compilation will fail. For example, this code will always fail: @Html.TextBox(name, ViewBag.Name). To work around this, either use ViewData[Name] or cast the value to a specific type: (string)ViewBag.Name.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset