The ASP.NET MVC framework is an emerging approach to building ASP.NET applications. Clearly inspired by Castle MonoRail, the ASP.NET MVC framework is based on an extremely popular Web adaptation of the Model-View-Controller pattern -- the Model2 pattern. Microsoft likes to contrast the ASP.NET MVC framework to Web forms by calling them cars and motorcycles. It's a nice analogy. Both cars and motorcycles can take you somewhere else, but with different speed and comfort. Classic ASP.NET is the more comfortable car; the MVC framework is the motorcycle, which is cheaper and hardly gets stuck in traffic jam.
Classic ASP.NET is based on the Page Controller pattern -- an object receives the HTTP request for a given page and handles it. When done, the page controller does something that updates the view. As mentioned, the ASP.NET MVC framework is based on a variation of MVC and takes a more direct route to executing operations. Let's see.
On top of the MVC framework there's a sort of front controller -- the ASP.NET routing subsystem. This component intercepts any HTTP request directed at the site. It parses the URL trying to match it to a list of patterns the developer provided. The typical URL pattern is as follows:
http://server/.../{controller}/{action}/{id}.
controller, action, and id indicate tokens in the URL that do not point to a physical resource on the server, but rather communicate to the routing system what to do. In global.asax you have the following code to register supported URL patterns:
protected void Application_Start()
{
RegisterRoutes(RouteTable.Routes);
}
public static void RegisterRoutes(RouteCollection routes)
{
routes.MapRoute("Default",
"{controller}/{action}/{id}",
new { controller = "Home", action = "Index", id = "" });
}
Each map route has a name, a pattern, and some default values. The routing system contains some (replaceable) logic to map the request to a route handler. The route handler is ultimately responsible for the action. The default route handler is invisible to developers and the first thing it does is extracting the {controller} and {action} tokens from the URL. If {controller} matches a class in the Web application, the handler instantiates the controller and invokes on it a method that corresponds to the {action} token.
As a developer, you organize your site as a collection of controller classes and related views. All the possible actions that the user of a Web site can accomplish are mapped as action on controller classes. Each action is mapped to a route. The routing system and its route handler companion class coordinate operations.
What's a controller? Quite simply, it is a public class that inherits from the base Controller class and follows a naming convention -- the string in the {controller} token trailed by Controller. Here's a quick example:
public class HomeController : Controller
{
public ActionResult Index()
{
ViewData["Title"] = "Home Page";
ViewData["Message"] = "Welcome to ASP.NET MVC!";
return View();
}
}
The controller indicates the action to execute. What about the user interface? The controller is also responsible for instructing the view object to produce HTML. The view object produces HTML based on an ASPX page living under the Views folder. The ASPX page has a code-behind class but usually does all of its work through markup and ASP-style code blocks. In ASP.NET MVC framework the view is an extremely thin object:
<h2><%= Html.Encode(ViewData["Message"]) %></h2>
Communication between controller and view occurs through a container -- the ViewData object.
With the ASP.NET MVC framework, applications go through a simpler runtime environment, but any action has to be expressed in terms of neat action. Not ideal for any website, but just great where it works.
