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 Routing pipeline consists of the following high-level steps when a request is handled by ASP.NET:
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.
The RouteData property of the RequestContext that is used throughout MVC is where the ambient route values are kept.