首页 > 代码库 > MVC之前的那点事儿系列（9）：MVC如何在Pipeline中接管请求的？(转载)
MVC之前的那点事儿系列（9）：MVC如何在Pipeline中接管请求的？(转载)
文章内容
上个章节我们讲到了，可以在HttpModules初始化之前动态添加Route的方式来自定义自己的HttpHandler，最终接管请求的，那MVC是这么实现的么？本章节我们就来分析一下相关的MVC源码来验证一下我们的这个问题。
先创建一个MVC3的Web Application，选择默认的模板以便创建以后就默认包含HomeController和AccountController。我们知道MVC要先接管请求才能通过这些Controller来处理，那我们先去Global.asax.cs文件里看代码（定义接管请求要在初始化HttpModule之前，所以只能到这里来找代码（或者是利用WebActivator之类的特性来动态添加），Global.asax.cs文件里代码很少，但是有我们需要的东西，首先在Application_Start的方法里发现一行代码：
RegisterRoutes(RouteTable.Routes);
这行代码，看调用的方法名称RegisterRoutes是注册Route的意思，但是为什么参数却是全局的RouteTable.Routes集合呢？找到RegisterRoutes方法来看看具体的内容：
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 = UrlParameter.Optional } // Parameter defaults );}
该方法有2行代码，第一行是忽略一个Route（我们先不看这个），第二行是使用MapRoute方法注册一个新的Route，默认是映射到Home Controller的Index Action上，我们可能想到了，RouteCollection（也就是刚才传入的RouteTable.Routes）的MapRoute方法就是提供我们所说的接管请求的入口，但是如何把MVC自己的HttpHandler传进去的呢？我们Go to一下这个MapRoute方法（需要安装ReShaper来查找MVC的源码），调整到了MVC的RouteCollectionExtensions类，发现MapRoute并不是RouteCollection自带的方法，而是在MVC源码里提供的一个扩展方法，代码如下：
public static Route MapRoute(this RouteCollection routes, string name, string url, object defaults, object constraints, string[] namespaces){ if (routes == null) { throw new ArgumentNullException("routes"); } if (url == null) { throw new ArgumentNullException("url"); } Route route = new Route(url, new MvcRouteHandler()) { Defaults = new RouteValueDictionary(defaults), Constraints = new RouteValueDictionary(constraints), DataTokens = new RouteValueDictionary() }; if ((namespaces != null) && (namespaces.Length > 0)) { route.DataTokens["Namespaces"] = namespaces; } routes.Add(name, route); return route;}
该代码的主要作用是new一个新的Route，然后将该Route添加到我们刚才提到的静态集合RouteTable.Routes里，以便后期查找Handler的时候使用，OK，这一步符合我们前面章节的分析。
接下来看，Route是如何new出来的，代码里的参数传入的分别是我们知道的url，以及一个MVCRouteHandler的实例，这一步也符合我们前面的分析，那我们来看一下MVCRouteHandler的GetHttpHandler方法是如何实现的获取MVCHandler的：
public class MvcRouteHandler : IRouteHandler { private IControllerFactory _controllerFactory; public MvcRouteHandler() { } public MvcRouteHandler(IControllerFactory controllerFactory) { _controllerFactory = controllerFactory; } protected virtual IHttpHandler GetHttpHandler(RequestContext requestContext) { requestContext.HttpContext.SetSessionStateBehavior(GetSessionStateBehavior(requestContext)); return new MvcHandler(requestContext); } protected virtual SessionStateBehavior GetSessionStateBehavior(RequestContext requestContext) { string controllerName = (string)requestContext.RouteData.Values["controller"]; IControllerFactory controllerFactory = _controllerFactory ?? ControllerBuilder.Current.GetControllerFactory(); return controllerFactory.GetControllerSessionBehavior(requestContext, controllerName); } #region IRouteHandler Members IHttpHandler IRouteHandler.GetHttpHandler(RequestContext requestContext) { return GetHttpHandler(requestContext); } #endregion }
看以上的粗体代码，MvcRouteHandler在实现了IRouteHandler的GetHttpHandler，该方法调用了MvcRouteHandler自身定义的GetHttpHandler虚方法，而在这个虚方法里我们看到了一个非常重要而又期待已久的代码——返回MvcHandler的实例，大概看一下MvcHandler这个类，得到它就是我们所猜想的：继承于IHttpHandler接口的一个类，并且也继承了 IHttpAsyncHandler接口，我们先不管MvcHandler内部是如何实现的，但我们前面几章节的全部分析终于得到了验证，也就说在这里得到了Mvc的专用处理Handler，然后调用它的BeginProcessRequest方法进入Mvc自身的Pipeline进行处理了。
至此，我们终于弄明白了Mvc在整个ASP.NET Runtime是如何接管请求的了，也应该大概清楚整个ASP.NET Runtime的运行机制了，至于MvcHandler的实现方式，我们会在后面的很多章节逐一给大家分析每行代码，今天我们还有一个小任务，那就是：看完了Mvc的实现机制，我们能否自己来写一个自定义的HttpHandler通过Route动态注册进去，来实现我们自己的自定义扩展，我们来尝试着做一下吧。
第一步：建立HttpHandler类
public class TomHandler : IHttpHandler { public TomHandler(RequestContext requestContext) { // do nothing } public virtual void ProcessRequest(HttpContext context) { string url = context.Request.Url.AbsoluteUri; context.Response.Write("当前地址为：" + url); context.Response.End(); // 这里我们什么都不做，只输出URL地址 } public virtual bool IsReusable { get { return false; } } }
第二步：建立RouteHandler类
public class TomRouteHandler : IRouteHandler{ IHttpHandler IRouteHandler.GetHttpHandler(RequestContext requestContext) { return new TomHandler(requestContext); }}
在GetHttpHandler实现里，返回我们定义的TomHandler实例。
第三步：注册我们的Route和RouteHandler
protected void Application_Start(object sender, EventArgs e){ Route route = new Route("tom/{other}", new TomRouteHandler()); RouteTable.Routes.Add(route);}
我们设置成，只要访问tom文件夹下的任意文件或者子目录，都提示该URL。下面是我的测试结果：
访问：Http//localhost/tom/
结果：没有提示我们预想的结果（原因是不符合我们的规则）
访问：Http//localhost/tom/123/
结果：输出正常（说明TomHandler已经接管了该请求）
访问：Http//localhost/tom/123.aspx?id=123
结果：输出正常（也说明TomHandler已经接管了该请求）
在建立真实的tom文件夹，然后在里面建立一个 index.html文件（内容为123），然后访问Http//localhost/tom/index.html，规则符合我们的Route定义，但输出结果却不是我们预期的结果，而是123，怎么回事？还记得上一章节里谈到的RouteCollection的GetRouteData方法么？该方法是先判断URL对应的文件是否真实存在，如果存在就直接输出，如果不存在就再来找RouteData的数据，这就解释了上面的index.html路径为什么不是我们期望结果的原因了吧？。
注：如果你建立一个index.aspx文件，并在index.aspx.cs文件里写Response.Write代码输出123的话，该文件也会按照aspx页面的正常周期来执行（也就是说输出123字符串），如果你在<system.web>里的httpHandlers节点用remove命令把*.aspx的匹配设置去掉，那结果就只会输出index.aspx这个文件里的字符串了（包括里面内嵌的任何C#代码）。
最后总结了，到这里，我们已经知道了MvcHandler是如何接管请求的了，而且自己也做了一个简单的例子来验证这套机制。重新回顾一下前面的这么多篇文章，我们应该大概对ASP.NET RunTime, Pipeline以及ASP.NET MVC切入点应该有个整体的了解了。
同步与推荐
本文已同步至目录索引：MVC之前的那点事儿系列
MVC之前的那点事儿系列文章，包括了原创，翻译，转载等各类型的文章，如果对你有用，请推荐支持一把，给大叔写作的动力。
MVC之前的那点事儿系列（9）：MVC如何在Pipeline中接管请求的？(转载)