This article is based on a prerelease version of the ASP.NET MVC Framework. Details are subject to change.
Contents
All Routes Lead to a Factory
Factory Extensibility
Execution Is Just the Beginning
Selector Attributes
Filter Attributes
Custom Action Filters
Getting Results
The Action Is Over
Controllers are the lynchpins of the Model View Controller (MVC) design pattern. They are on the front line, first receiving a client’s requests, and then translating the requests into instructions for the model where your application’s domain logic and data reside. Controllers are also responsible for selecting a view for presenting information to the user.
In this article, I will dissect the ASP.NET MVC framework and look at how controllers work. I’ll explain how the framework interacts with your controllers and how you can influence those interactions. I’ll look at controller factories, controller actions, action filters, and action results as well.
I’ll dig in fairly deeply, so if you are looking for a more general introduction to the ASP.NET MVC framework, see Chris Tavares’ article “Building Web Apps without Web Forms.”
All Routes Lead to a Factory
It’s difficult to talk about the life of a controller without talking about routes. The routing table in an ASP.NET application contains the information necessary for the ASP.NET routing module to extract information from an incoming URL and direct the request to the proper software component. In January’s column, I looked at using the ASP.NET routing module with Web Forms (“Routing with ASP.NET Web Forms”.) In that column, I built my own routing handler in order to execute a Web form, but the ASP.NET MVC framework provides a routing handler that will eventually direct a request to one of our controllers.
For this MVC routing handler to process requests, you need to configure the routing table during application startup. The default routing configuration provided by the MVC project template lives in the global.asax file and is shown in Figure 1.
Figure 1 The Default Routing Configuration
One of the routing configuration entries in Figure 1 is a route named Default with an URL template of “{controller}/{action}/{id}”. This URL template is a pattern the routing engine will use to first see if an incoming URL is a match for this route. A URL that would match such a route would be http://localhost/home/index/. When the routing engine finds a match, it will again use the URL template as a pattern to lift parameters from the incoming URL. In this example, the string “home” becomes the controller parameter because it is in the {controller} position, and the string “index” becomes the action parameter.
The anonymously typed object constructed as the third parameter to MapRoute represents the default values for the routing engine to use if it cannot find a given parameter in the URL. In the case of http://localhost/home/index/, the routing engine doesn’t find “id” information in the URL, but it will still pass along an id parameter with the default value of an empty string. The routing engine passes all these parameters to a routing handler via a RouteData object.
It’s important to note that the routing engine knows nothing about ASP.NET MVC. The engine’s only job is to analyze URLs and pass control to a route handler. The MapRoute method being invoked inside of the RegisterRoutes method of Figure 1 is an extension method provided by the MVC framework. Every route registered with MapRoute is configured to use an MvcRouteHandler object—this is the route handler provided by the MVC framework. As you saw in the January column, it is the route handler’s job to find an HTTP handler for a request—that is an object implementing the IHttpHandler interface. In MVC applications, this object will be an object of type MvcHandler, and inside MvcHandler is where processing becomes interesting.
Figure 2 shows the processing flow for a typical MVC request. When control reaches the MvcHandler, the MvcHandler is able to extract the controller parameter from the RouteData produced by the routing module earlier in the processing. The handler will ultimately send this controller parameter, which is a string value, to a controller factory. It is then the factory’s responsibility to construct and return a controller. All controllers in an MVC application implement the IController interface.
Tags: asp.net, asp.net mvc framework, controller, extreme, implement, mvc, process, route, web form