Master Pages in VB.NET

Drawer QR Code in VB.NET Master Pages

If the view is not a partial view, it can have a master page. The master page in this context is exactly the same as the master page in Web Forms. It s a standard .master file, but it s located under the Views\Shared folder.

In ASP.NET MVC, a master page is implemented through the services of ViewMasterPage, which is defined as follows:

public class ViewMasterPage : MasterPage { public ViewMasterPage(); // Properties public AjaxHelper Ajax { get; } public HtmlHelper Html { get; } public object Model { get; } public TempDataDictionary TempData { get; } public UrlHelper Url { get; } public ViewContext ViewContext { get; } public ViewDataDictionary ViewData { get; } internal ViewPage ViewPage { get; } public HtmlTextWriter Writer { get; } }

As you can see, it extends the ASP.NET MasterPage class with the typical helpers and properties of ASP.NET MVC views, such as Html, Model, and ViewContext. By default, a master page in ASP.NET MVC doesn t require a code-behind class. However, if you need to expose your own programming model out of the master, you can use a <script> server-side tag (which is the recommended approach) or manually create code-behind classes. Here s a brief example:

public partial class SiteMasterExtended : System.Web.Mvc.ViewMasterPage { public string PageHeading { get { return this.__PageHeading.Text; } set { this.__PageHeading.Text = value; } } }

The sample master page class inherits from ViewMasterPage and just adds some properties. Most of the time, extra properties are mere wrappers around some of the controls embedded in the master page template, as shown in the following example:

Note that if you decide to add a code-behind class manually, you should ensure that Visual Studio also creates a designer class file (xxx.master.designer.cs) that includes references to server controls in the markup:

public partial class SiteMasterExtended { protected global::System.Web.UI.WebControls.Literal __PageHeading; ... }

To set properties exposed by the master view, you need to write a handler for the PreInit event in the page life cycle, as shown here:

<%@ Page MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage" %> <%@ MasterType TypeName="ProgMvc.Views.Shared.SiteMasterExtended" %> <script runat="server" Language="C#"> protected void Page_PreInit(object sender, EventArgs e) { this.Master.PageHeading = "s"; } </script> <asp:Content ...> ... </asp:Content>

In Web Forms, through a PreInit handler you could also switch master pages on the fly, as shown below.

protected void Page_PreInit(object sender, EventArgs e) { this.MasterPageFile = "~/Views/Shared/VertLayout.Master"; }

In ASP:NET MVC, you don t need this if you want to be able to switch master pages on the fly and based on runtime conditions. Because the generation of the view is distinct process in ASP.NET MVC, all you need to do is tell the view engine which master page it has to use.

public ActionResult Index() { ... return View("Index", "SiteMaster"); }

In ASP.NET MVC, any view is expected to be isolated from the controller code. The view should receive from the outside world any data it has to process. Data can be passed in two nonexclusive ways: via the ViewData dictionary and via an object model. As mentioned, ViewData is an object of type ViewDataDictionary. Any data you store in a dictionary is treated as an object and requires casting, boxing, or both in order to be worked on. A dictionary is definitely not something you would call strongly typed. At the same time, a dictionary is straightforward to use and works just fine.

ViewDataDictionary is kind of unique because it also features a few ASP.NET MVC specific properties such as the Model, ModelState, and ModelMetadata properties, as shown here:

public class ViewDataDictionary : IDictionary<string, object>, ICollection<KeyValuePair<string, object>>, IEnumerable<KeyValuePair<string, object>>, IEnumerable { public object Model { get; set; } public ModelStateDictionary ModelState { get; } public virtual ModelMetadata ModelMetadata { get; set; } ... }

The ModelState property gets information about the state of the model. It typically contains entries describing what s wrong, if anything, in the data being worked on in the view. The ModelMetadata property, instead, stores information about the data being processed by the view the model. Metadata includes display and edit information about properties of the model. Metadata information is obtained from a metadata provider. The default provider is based on the Data Annotations library. (See 6, Inside Models, and 7, Data Entry in ASP.NET MVC, for more details.) The Model property is an alternative and object-oriented way of passing data to the view object. Instead of fitting flat data into a dictionary, you can shape a custom object to faithfully represent the data the view expects. The Model property just gives you a chance to create a view-model object that is unique for each view. If you intend to use the Model property to pass data to the view, you have to make it explicit, as shown here:

public partial class YourPage : ViewPage<YourViewModel> { ... }

The view page class derives from ViewPage<T> instead of ViewPage. If you don t use a code-behind class, you achieve the same goal with the following page directive in the view file:

<%@ Page MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage<YourViewModel>" %>

The ViewData dictionary is good enough for quick-and-dirty or short-lived sites. However, it becomes inadequate as the complexity of the view (and the number of views) grows beyond a certain threshold. So what should you do