Under the Hood: How Routes Tie Your URL to an Action
This section provides a peek under the hood to get a detailed understanding of how these pieces tie together. This will give you a better picture of where the dividing line is between routing and MVC.
One common misconception is that routing is just a feature of ASP.NET MVC. During early previews of ASP.NET MVC 1.0, this was true, but it quickly became apparent that Routing was a useful feature in its own right beyond ASP.NET MVC. For example, the ASP.NET Dynamic Data team was also interested in using Routing. At that point, Routing became a more general-purpose feature that had neither internal knowledge of nor a dependency on MVC.
To better understand how routing fits into the ASP.NET request pipeline, let's look at the steps involved in routing a request.
The discussion here focuses on routing for IIS 7 (and above) Integrated Mode. There are some slight differences when using routing with IIS 7 Classic Mode or IIS 6. When using the Visual Studio built-in web server, the behavior is very similar to the IIS 7 Integrated Mode.
The High-Level Request Routing Pipeline
The routing pipeline consists of the following high-level steps:
1. The UrlRoutingModule attempts to match the current request with the routes registered in the RouteTable.
2. If a route matches, the Routing module grabs the IRouteHandler from that route.
3. The Routing module calls GetHandler method of the IRouteHandler, which returns the IHttpHandler that will be used to process the request.
4. ProcessRequest is called on the HTTP handler, thus handing off the request to be handled.
5. In the case of ASP.NET MVC, the IRouteHandler is an instance of MvcRouteHandler, which, in turn, returns an MvcHandler that implements IHttpHandler. The MvcHandler is responsible for instantiating the controller, which in turn calls the action method on that controller.
RouteData
Recall that when the GetRouteData method is called it returns an instance of RouteData. What exactly is RouteData? RouteData contains information about the route that matched that request.
Earlier we showed a route with the following URL: {controller}/{action}/{id}. When a request for /albums/list/123 comes in, the route attempts to match the request. If it does match, it then creates a dictionary that contains information parsed from the URL. Specifically, it adds a key to the dictionary for each URL parameter in the route URL.
In the case of {controller}/{action}/{id}, the dictionary will contain at least three keys: “controller,” “action,” and “id.” In the case of /albums/list/123, the URL is parsed to supply values for these dictionary keys. In this case, controller = albums, action = list, and id = 123.