This is a continuation of my Introduction to ASP.NET MVC series. As I outlined before this is in an effort to write the book and keep blogging, I decided to write/blog the last chapter, Chapter 2. I am doing this so I can receive feedback on this chapter as early as possible. Because this chapter, in my opinion, is probably the most critical of the book, it defines the context around ASP.NET MVC and how it differs from ASP.NET Web Forms, as well as giving a historical perspective of the MVC pattern.

In the next several posts we will cover the following parts of Chapter 2 from the book:

• The Model-View-Controller Pattern
• ASP.NET MVC vs. ASP.NET Web Forms
• Installing the Prerequisites
• Your First ASP.NET MVC Project
• The Model
• The View
• The Controller

ASP.NET MVC 1.0 Website Programming: Problem – Design – Solution by Nick Berardi New: $31.49 This item has not yet been released. You may order it now and we will ship it to you when it arrives.

The View

In ASP.NET MVC, the view is the presentation of your applications’ business layer or model.  Typically with ASP.NET MVC this is HTML, but your view can be rendered in any form that can be transmitted over the internet, including JSON, XML, binary, RSS, ATOM, and your own customized protocol if you have one.

These dynamic ranges of views that, allow it to be capable of such a wide range of delivery types in the ASP.NET MVC Framework are because of a provider engine appropriately called the view engine.  The view engine is responsible for taking the controller and action names and then delivering the right view based on these names.

When I talk about the view engine from here on forward, I will be specifically referring to the ASP.NET MVC implementation, called WebFormViewEngine, which is based on the aspx, ascx, and master files.  There are many other types of view engines, such as Brail, NHaml, NVelocity, and XSLT that are available from the MVC Contrib project located at www.codeplex.com/mvccontrib, if you are interested in learning more.

ViewEngine

The default ViewEngine in the ASP.NET MVC Framework, the WebFormViewEngine, uses a hierarchy of folders and aspx and ascx files when rendering HTML pages to the browser.  The WebFormViewEngine, uses the standard ASP.NET Web Forms rendering engine that has been present in the framework since version 1.0, however the emphasis has been moved from control based rendering to an inline code based rendering that is reminiscent of its predecessor, plain old ASP.

Let’s take another look at the hierarchy that the default view engine uses, as seen in Figure 2-24.

Figure 2-24

The view engine treats aspx and ascx files almost equally, so that it is possible to render your HTML from an ascx or user control file, in the same way that an aspx or page file works.  As you can probably imagine there needs to be a hierarchy or order to which an aspx or ascx file is picked from the controller or Shared directory in Figure 2-24.  The default ASP.NET MVC view engine uses the following lookup order, from top to bottom, when trying to determine which view to render.

1. ~/Views/{controller}/{action}.aspx
2. ~/Views/{controller}/{action}.ascx
3. ~/Views/Shared/{action}.aspx
4. ~/Views/Shared/{action}.ascx

What this above lookup order means is that:

• Controller directories are always checked before the Shared directory.
• aspx or page files are always checked before the ascx or user control files.

The above lookup order even applies to master files, which allows you to select the master page template that you want to render with your view.  The lookup order that the master pages follows is slightly different than the page and user controls:

1. ~/Views/{controller}/{master_name}.master
2. ~/Views/Shared/{master_name}.master

Now that we have learned how view pages, controls, and master page are selected let’s take a little closer look at the files themselves.

ViewMasterPage, ViewPage, and ViewUserControl

In ASP.NET MVC there are three new takes on objects that you are probably familiar with from ASP.NET Web Forms.  These types probably come as no surprise, given what we just covered in the ViewEngine section and the title of this section, but they are as follows listed with their Web Form equivalent.

These object types in MVC are actually inherited from their Web Form counterparts, because they rely on their built in execution, in the ASP.NET Core, as a way of delivering the content through the servers such as IIS.  So all the interfaces you have become acustumed to (i.e. User, Context, Request, Response, IsPostBack, etc.) are still available in the MVC version of the page, user control, and master page.

However when developing for MVC there is a primary difference in the way in which an MVC view is constructed in the code-behind compared to its Web Form counterpart.  The best way to illustrate this difference is by showing you all that this required to have a fully functional view in MVC:

public partial class MyViewPage : ViewPage
{
}

Yup, that is all that is required, pretty cool huh?  This is possible because all the application logic that used to be in button clicks, post backs, and other event actions, has been moved to the controller actions.

It is actually considered bad practice in ASP.NET MVC to put any code in the code-behind file.

We have covered the basics of how views are rendered and found and the differences between MVC views compared to their Web Form counterparts.  We will be going in to a great depth of detail on programming views in later chapters of this book.  However we are not quite done, there are a couple more basics things I want to cover before moving on to The Controller section.  These include special properties designed to allow easy communication between the model, controller and view.

I have broken up the properties in to logical sections, so that we can discuss the purpose and intended use of each of them as envisioned by the ASP.NET MVC team.

ViewData, and Model

The ViewData property is used to store and transmit data from the model and controller to the view for rendering.  It can either be used as a Dictionary object, such as:

<%= ViewData["text"] %>

Or as a typed model object, such as:

<%= ViewData.Model.CustomerID %>

That is defined using generics in the inheriting object, such as a Customer type in the ViewPage:

public partial class EditCustomer : ViewPage<Customer>

It is a very versatile collection that is available to both the views and the controllers, and is passed via the ViewContext, which inherits from the ControllerContext.

TempData

The TempData property is a session-backed temporary storage dictionary, much like ViewData, which is available for the current request, plus one.  What this means is that any data you store in the TempData is kept in the session storage for one additional request, beyond the one you’re currently processing.

You may be scratching your head like I was when I first learned about TempData, and wondering why this would be important enough to include in the framework.  There is actually a very simple answer to this question, it allows you to pass data across requests, much like you have been accustomed to with the ViewState that is used in Web Forms.  It is also great for passing data between redirects, say you have the following scenario:

A user comes in to your site unauthenticated and you have to redirect them to the login page, but you what to display a message saying they need to login before viewing the content, but that message should display only when they don’t visit the login page directly.

Previously to accomplish this type of process you had to jump through hoops to determine if the user came from another page on your site, by checking the referrer or some other custom process that you had to come up with.  Additionally even after you got this done it was hard to customize that message to give the user some indication of where they came from or are going after they login.  TempData really comes to the rescue in this case, because you can the following is the only code that you need to display that message:

<% if (TempData["Message"] != null) { %>
<div class="message"><%= TempData["Message"] %></div>
<% } %>

You can even put this code in your master page so that you can display a message to your user on any page in your site, and all that you need is these three lines of code in the view.

HTML and AJAX Extension Methods

The HTML and AJAX extension methods provide a way to generate snippets of code for such things as form inputs and links.  For example if you wanted to generate a text box with the name attribute set to CustomerName, you just need to put the following in your view:

<%= Html.TextBox("CustomerName") %>

And it will generate the following HTML:

<input type="text" name="CustomerName" id="CustomerName" value="" />

As one added feature if you actually wanted to render the page with CustomerName already filled in, you would just need to set ViewData["CustomerName"], in the controller, equal to whatever you want to be rendered in the HTML.

An extension method for all of the form inputs available through HTML, have been provided with the ASP.NET MVC Framework, plus some other extensions such as AJAX implementations of the form inputs, and anchor link generation for controller actions.  Ninety-nine percent of all the HTML and AJAX extension methods that you will need to generate a web page have been provided in the framework, and if there is something that you must have, you can extend your own method from the HTML helper by doing the following:

public static string MyCustomControl (this HtmlHelper html, string name)

The this keyword is what is used to add these custom methods on to the HtmlHelper, which is represented as Html in the view pages, we will cover extension methods in greater detail later on in Chapter 6.

This post is licensed under a different license than the rest of my site. Copyright © Wiley Publishing Inc 2009

This is a continuation of my Introduction to ASP.NET MVC series. As I outlined before this is in an effort to write the book and keep blogging, I decided to write/blog the last chapter, Chapter 2. I am doing this so I can receive feedback on this chapter as early as possible. Because this chapter, in my opinion, is probably the most critical of the book, it defines the context around ASP.NET MVC and how it differs from ASP.NET Web Forms, as well as giving a historical perspective of the MVC pattern.

In the next several posts we will cover the following parts of Chapter 2 from the book:

• The Model-View-Controller Pattern
• ASP.NET MVC vs. ASP.NET Web Forms
• Installing the Prerequisites
• Your First ASP.NET MVC Project
• The Model
• The View
• The Controller

ASP.NET MVC 1.0 Website Programming: Problem – Design – Solution by Nick Berardi New: $31.49 This item has not yet been released. You may order it now and we will ship it to you when it arrives.

The Model

In ASP.NET MVC, the model referrers to your applications’ business layer or domain objects.  These objects are responsible for persisting the state of your application, which is often, but note necessarily, stored in a database.

There really isn’t much to explain about the model as it relates to the ASP.NET MVC Framework, because it is based on your implementation and design of your business layer.  You can use any design pattern, methodology, and or custom process to accomplish the creation of the model:

• DDD (Domain Driven Design)
• TDD (Test Driven Design)
• ALT.NET
• Repository Pattern
• Service Pattern
• Specification Pattern
• POCO (Plain Old CLR Object)
• LINQ To SQL
• ADO.NET Entity Framework
• NHiberante
• Data Tables
• Your custom own business layer
• Any combination of the above.

The point behind all of this is to try to demonstrate that it is up to you to define the model.  It is up to you to make the best decisions related to your requirements.  It is up to you to make it as simple or as complex as needed.  Everything is up to you, when we are talking about the M in MVC.

This post is licensed under a different license than the rest of my site. Copyright © Wiley Publishing Inc 2009

This is a continuation of my Introduction to ASP.NET MVC series.  As I outlined before this is in an effort to write the book and keep blogging, I decided to write/blog the last chapter, Chapter 2.  I am doing this so I can receive feedback on this chapter as early as possible.  Because this chapter, in my opinion, is probably the most critical of the book, it defines the context around ASP.NET MVC and how it differs from ASP.NET Web Forms, as well as giving a historical perspective of the MVC pattern.

In the next several posts we will cover the following parts of Chapter 2 from the book:

• The Model-View-Controller Pattern
• ASP.NET MVC vs. ASP.NET Web Forms
• Installing the Prerequisites
• Your First ASP.NET MVC Project
• The Model
• The View
• The Controller

ASP.NET MVC 1.0 Website Programming: Problem – Design – Solution by Nick Berardi New: $31.49 This item has not yet been released. You may order it now and we will ship it to you when it arrives.

Your First ASP.NET MVC Project

To create your first ASP.NET MVC Project, you only need the prerequisites listed in the previous section.  To start, you first need to open Visual Web Developer 2008 or any version of Visual Studio 2008.

For the purpose of this section I will be using Visual Studio 2008 Team Development Edition.  I have, however, verified that this process works on Visual Web Developer 2008 SP1, Visual Studio 2008 Professional, and Visual Studio 2008 Team Development Edition.

After Visual Studio is open we need to create a new project (File > New > Project), see Figure 2-16 for an example.

Figure 2-16

Doing this will put you in the New Project screen, which you will then select your preferred language (in our case Visual C#).  From there we need to select Web @@> ASP.NET MVC Web Application, as depicted in Figure 2-17.

Figure 2-17

I am going to leave all the project configuration fields set to their default values as shown in Figure 2-17, you may configure them however you desire.  When you are done click OK, and you will see the screen shown in Figure 2-18.

Figure 2-18

You have probably not seen a screen like this before, even if you have done ASP.NET Web Forms development.  It is totally new to the ASP.NET MVC project creation process, and it automatically creates a unit testing project based on the default MVC project.

As an added feature it also allows you to select the testing framework that you would like to use, even non-Microsoft ones, such as NUnit, MbUnit, XUnit, Visual Studio Unit Test, and any others that decide to provide an interface to this Visual Studio process.

You can choose to create a unit project, or wait till a later time if desired.  For the purpose of this demonstration I am going to create a unit test project using MbUnit v3 from the drop down.  When you are done click OK, and you will see a Solution Explorer that looks like Figure 2-19.

Figure 2-19

This is what the default folder and file structure looks like for the ASP.NET MVC project, it has a separate folder for Models, Views (as seen in Figure 2-21), and Controllers (as seen in Figure 2-20).  As well as a set of default folders for storing JavaScript, CSS, or anything else you would want to deliver from your web application (as seen in Figure 2-22).

Figure 2-20

There are two controllers created by default.  The HomeController is used to render the home page and the about page.  The AccountController is used to authenticate a user with the standard ASP.NET membership provider.  These two controllers provide you everything you need to create a very basic web application.

Figure 2-21

For the views there is a mirroring of the controllers created.  One for Account and another for Home, in these folders there are aspx files that are call views.  Each of these views mirror an action method from the controller, by default.  As you will see later in this book there is a many to many relationship between the views and action methods.  In that an action method can map to multiple views and a view can have multiple action methods that use it.  Let’s not get to in-depth about the mapping of views and action methods at this point, because we will cover this in great detail later in this chapter and future chapters when implementing our application.

There is also a shared folder called Shared, which is, for lack of a better word, shared between all of the controllers and can be called by any of the controllers in the project.

The last thing I want to talk about before we move on to the rest of the files in the solution, is what appears to be a rouge Web.config file located under the Views directory.  This is a deliberate and strategic Web.config that is used, in addition to the one in the root, to block access to all the aspx files from getting accessed directly.  This Web.config file contains the following configuration information:

<?xml version="1.0"?>
<configuration>
	<system.web>
		<httpHandlers>
			<remove verb="*" path="*.aspx"/>
			<add path="*.aspx" verb="*" type="System.Web.HttpNotFoundHandler"/>
		</httpHandlers>
	</system.web>

	<system.webServer>
		<validation validateIntegratedModeConfiguration="false"/>
		<handlers>
			<remove name="PageHandlerFactory-ISAPI-2.0"/>
			<remove name="PageHandlerFactory-ISAPI-1.1"/>
			<remove name="PageHandlerFactory-Integrated"/>
			<add name="BlockViewHandler" path="*.aspx" verb="*" preCondition="integratedMode" type="System.Web.HttpNotFoundHandler"/>
		</handlers>
	</system.webServer>
</configuration>

It contains both configuration information for IIS 7, <system.webServer />, and IIS 6 and lower, <system.web />.  So you will be covered on which ever server you decide to deploy your MVC application to.

Figure 2-22

The rest of the solution files, includes JavaScript, Style Sheets, and other ASP.NET files that you should be familiar with.  The JavaScript files that are included by default are Microsoft AJAX and jQuery, as well as debug version of the files.

In the Fall of 2008, Microsoft announced a partnership with jQuery (www.jquery.com) to provide support and deliver jQuery with Visual Studio 2010 and some key projects.  One of the key projects that jQuery will be delivered with, is ASP.NET MVC.

If you are going to be using jQuery heavily in your application, as we are in this book, I highly recommend that you download the latest version of jQuery and the Visual Studio Intellisense Documentation for jQuery.  jQuery is constantly being developed and new features are getting added all the time, so it really pays to be running the latest version, so be sure to get the latest production and development files:

http://www.jquery.com

There are some standard ASP.NET files that we have all seen before, but I would like to take this opportunity to give you a quick overview of the purpose of the Global.asax and Default.aspx files.  These two files have a special purpose in an MVC application that you should be made aware of.

Global.asax

This is a standard ASP.NET file.  MVC takes advantage of the file to initialize all the URL routes, for mapping actions and controllers to URL’s, when the application is first started, using the Application_Start event handler.

public static void RegisterRoutes(RouteCollection routes)
{
	routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

	routes.MapRoute(
		"Default",
		"{controller}/{action}/{id}",
		new { controller = "Home", action = "Index", id = "" }
	);
}

protected void Application_Start()
{
	RegisterRoutes(RouteTable.Routes);
}

Default.aspx

This is a standard ASP.NET file.  It is not necessary on IIS 7, because of IIS 7′s integrated pipeline.  However you should not worry about it being present on and IIS 7 MVC application because, it will not interfere with the execution of the code.  The sole purpose, of this file, is to handle root requests on IIS 6 and lower, it does this using the Page_Load event handler of the page and forcing the request through the MvcHttpHandler, instead of rendering the page, which is empty.  The Page_Load event handler is shown in the code below.

public void Page_Load(object sender, System.EventArgs e)
{
	HttpContext.Current.RewritePath(Request.ApplicationPath);
	IHttpHandler httpHandler = new MvcHttpHandler();
	httpHandler.ProcessRequest(HttpContext.Current);
}

The final thing I want to cover is what the default ASP.NET MVC application design looks like when running in a browser, you can see an example of this in Figure 2-23.

Figure 2-23

It is a pretty basic layout, but it is a good example of the Home and Account controllers and can be used to render to and interact with the browser.

In the rest of this chapter, we are going to cover the basics of the ASP.NET MVC Framework, with a specific focus on the Model, View, and Controller.  So let’s get started.

This post is licensed under a different license than the rest of my site. Copyright © Wiley Publishing Inc 2009