The basics of ASP.NET MVC routes (excerpt from ASP.NET MVC in Action)
(excerpt from ASP.NET MVC in Action).

The Global.asax.cs file contains some routes that are provided with the MVC Web Application project. Before continuing, we must define what a route is. A route in the ASP.NET MVC Framework is the complete definition for how to handle a web request. With Web Forms, we have little control over this without resorting to url rewriting. With Web Forms, the url of the web request is tightly coupled to the page handling the request. If the page was named Foo.aspx in a folder named Samples, then the url was sure to be http://mvccontrib.org/Samples/Foo.aspx. Many teams have resorted to url rewriting to wrangle some control over the urls and how to satisfy each request. With the ASP.NET MVC Framework, routes are first class citizens in the web application. We start with defining how we want our urls structured. The project template gives us a few routes to start, shown in Listing 1.1.
Listing 1.1 Default routes for a new project. These are added by the project template.
using System.Web; using System.Web.Mvc; using System.Web.Routing; namespace GettingStarted { public class GlobalApplication : HttpApplication { public static void RegisterRoutes(RouteCollection routes) { routes.IgnoreRoute("{resource}.axd/{*pathInfo}"); routes.MapRoute( "Default", // Route name "{controller}/{action}/{id}", // URL with parameters new {controller = "Home", action = "Index", id = ""} ); // Parameter defaults } protected void Application_Start() { RegisterRoutes(RouteTable.Routes); } } }
Routes need to be defined as one of the first things when the web application starts up, so the project template adds the routes to the Application_Start method in the Global.asax.cs file. Later in the book, you'll see that we don't leave the routes in this location except for the most trivial of web applications.
Note
We will follow long-standing best practices of Separation of Concerns and the Single Responsibility Principle , or SRP, by moving the routes to a dedication location separated by an interface. We'll go more into these principles later, but, in short, the responsibility (or concern) of the Application_Start method is to kick off operations that must happen at the beginning of the application's life. The responsibility is not to perform every bit of work that must happen on start. Any operations that must happen on application start should reside in separate classes and merely be called in the appropriate order in the Application_Start method.
Note that the url portion of the route is simply a matching mechanism for the request. If the url matches a particular route, then we specify what controller should handle the request and what action method should execute. You can create as many routes as you like, but one route is provided for you. This route has the template, {controller}/{action}/{id}.
Note
This is a very generic route and could be used for many, many different web requests. Tokens are denoted by the inclusion of {braces}, and the word enclosed in braces matches with a value the MVC Framework understands. The most common that we'll be interested in are controller and action. This is the route we will be using for the rest of the chapter, so we will be content with a url in the form of http://mvccontrib.org/controllername/actionname. The basic RouteHandler is an instance of IRouteHandler and we'll use MvcRouteHandler most of the time. We have complete control and could provide our own implementation of IRouteHandler if we wished, but we'll save that for a later chapter.
Before we spin up our first controller, let's examine what is different about the web.config file in an MVC Web Application project. The differences are easy to spot. Just look for “routing” or “mvc”. One difference we see is that a new IHttpModule is registerd in the config file. Here, we see the UrlRoutingModule in listing 1.2
Listing 1.2 Unique addition to the web.config file. The rest of the web.config file is standard for .Net 3.5.
<add name="UrlRoutingModule" type="System.Web.Routing.UrlRoutingModule, System.Web.Routing, Version=0.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
The UrlRoutingModule evaluates a request and sees if it matches a route that is stored in the RouteTable. If the route matches, it overrides the default handler (IHttpHandler) for the request so that the MVC Framework handles the request. We are going to examine our first controller as a means to handle a route for the url /home. In the next section you will see how all the pieces of the starter project fit together.
Stay tuned for more: My feed: http://feeds.jeffreypalermo.com/jeffreypalermo
You will also want to pay attention to my co-authors: Ben Scheirman and Jimmy Bogard.





Depending on how long you’ve been building web applications on the Microsoft platform, you’ll relate to some or all of the following pain. In the 1990’s, developers built interactive websites using executable programs that ran on a server. These programs (CGI was a common technology at the time) accepted a web request and were responsible for creating an Html response. Templating was ad-hoc, and the programs were difficult to write, debug and test. In the late 1990’s, Microsoft, after a brief stint with Htx templates and Idc connectors, introduced Active Server Pages, or ASP. Active Server Pages brought templating to web applications. The server page was an Html document with dynamic script mixed in. While this was a big step forward from the alternatives, the world soon saw massive server pages with code indecipherable from the markup. In early 2002, along came ASP.NET. ASP.NET was a complete shift for ASP developers because it moved all server page code into a class file and replaced the Html markup with dynamic server controls in an Xml syntax. While performance increased, and the debugging experience improved, new problems arose. The server-side postback event lifecycle caused newsgroups to explode with activity as developer searched for the magic event in which to add those two simple lines of code. Viewstate, while good in theory, broke down as the application scaled with complexity. Simple pages broke 100KB in size, most of which was the Viewstate. Perhaps the greatest sin of the ASP.NET framework was the tight coupling to everything in the System.Web namespace. There was no hope of unit testing any code in the code-behind file, and today we see Page_Load methods that take several trees to print.
MLS: 4880240
We are announcing a 10% discount for early registration that goes to September 15th. Register before August 31, and you'll receive 10% off the price.
Introduction