ASP.NET MVC 4源码分析之如何定位控制器

浏览数：52 / 时间：2015年06月09日

利用少有的空余时间，详细的浏览了下ASP.NET MVC 4的源代码。照着之前的步伐继续前进（虽然博客园已经存在很多大牛对MVC源码分析的博客，但是从个人出发，还是希望自己能够摸索出这些）。首先有一个事实我们需要明白，就是ASP.NET MVC是基于ASP.NET的，并不是独立开来的，所以我们的伊始将会从路由配置入手。

在开始本节之前，需要读者对ASP.NET的路由配置以及C#的扩展方法有一定的掌握，如果读者不理解请根据情况选择下面的文章进行充电：

1.ASP.NET路由映射

2.C#扩展方法

RouteCollectionExtensions.cs

下面我们打开任意一个ASP.NET MVC项目（以下示例均为ASP.NET MVC 4，如果是其他版本请到响应的文件中查找），打开路由映射的文件（MVC4为App_Start下的RouteConfig.cs文件），可以看到我们再也熟悉不过的配置了，下面我们就来看看MapRoute背后的源码是什么样的

 1         public static Route MapRoute(this RouteCollection routes, string name, string url, object defaults, object constraints, string[] namespaces)
 2         {
 3             if (routes == null)
 4             {
 5                 throw new ArgumentNullException("routes");
 6             }
 7             if (url == null)
 8             {
 9                 throw new ArgumentNullException("url");
10             }
11             //这里的MvcRouteHandler就是一个重要的切入点
12             Route route = new Route(url, new MvcRouteHandler())
13             {
14                 Defaults = new RouteValueDictionary(defaults),
15                 Constraints = new RouteValueDictionary(constraints),
16                 DataTokens = new RouteValueDictionary()
17             };
18             //而这里的DataTokens仅仅只是作为附加的参数
19             //作为后面搜索控制器时的一个条件
20             if ((namespaces != null) && (namespaces.Length > 0))
21             {
22                 route.DataTokens["Namespaces"] = namespaces;
23             }
24             routes.Add(name, route);
25             return route;
26         }

View Code

这个方法是对RouteCollection的扩展，其实就是RouteTable的Routes。我们可以看到源码完全是利用ASP.NET的路由映射创建的，其中的关键点就是这个MvcRouteHandler，这是讲所有符合的请求都经由MVC处理的入口。

MvcRouteHandler.cs

我们顺藤摸瓜来到了MvcRouteHandler，这个类自然也要符合ASP.NET的要求，所以要实现IRouteHandler接口，其中有个关键的方法就是GetHttpHandler，这个方法要求返回一个实现了IHttpHandler接口的类型，而我们可以轻松的看到最终返回了一个MvcHandler类型

MvcHandler.cs

紧接着我们来到MvcHandler这个类，可以看到它不仅仅实现了IHttpHandler接口，同时还实现了IHttpAsyncHandler和IRequiresSessionState接口，前者是为了实现异步控制器，后者是为了访问会话（Session）

然后我们查看接口是如何实现的

（IHttpHandler中ProcessRequest的实现）

（IHttpAsyncHandler中BeginProcessRequest的实现）

PS：这部分代码比较长，所以没有全部截取，并且重点也不在那。

通过两个截图读者可以看到笔者红色框住的部分，也能够知道他们是我们接下来的主角，从它的参数也能够看出这个方法将会返回给我们控制器的实现（IController）。下面我们长话短说，直接看这个方法中的关键部分

这里首先通过路由参数获取了控制器的名称，然后调用ControllerBuilder的GetControllerFactory方法获取控制器工厂，我们可以简单的看下GetControllerFactory的是如何实现的

ControllerBuilder.cs

呵呵，这当然我们要看的，下面我们会看到Current的具体类型

这里笔者就没有继续探索进去了，因为我们已经得出控制器工厂的具体类型是DefaultControllerFactory，那么我们回到MvcHandler中，可以看到在获取了控制器工厂之后，就调用了它的CreateController方法，所以我们就打开DefaultControllerFactory.cs文件一探究竟。

DefaultControllerFactory.cs

二话不说，我们直接Search关键字CreateController就看到了下面这段代码

OK，我们可以看到在CreateController中首先调用了GetControllerType获取控制器的类型，然后再通过GetControllerInstance将控制器创建出来，既然本文的目的是探索控制器是如何定位查找的，所以我们就从GetControllerType入手，接招看代码 J

上图仅仅只是默认命名空间的情况，如果读者指定了查找的命名空间则是另外实现的代码，但是其中都是通过调用GetControllerTypeWithinNamespaces来查找的，所以我们就不必在此就留，直接F12来到这个方法中

到了这里，我们不能盲目自信，看到GetControllerTypes就兴冲冲的F12进去，因为在这个方法之前的EnsureInitialized才是真正的关键部分，所以我们要跟进去。

ControllerTypeCache.cs

下面是EnsureInitialized的具体代码

其中我们看到它首先是判断_cache是否为NULL，如果不为NULL是不会进行下面的操作的，这就是为什么第一次访问页面的时候会很慢，而之后就很快了，原因就在这了。当然我们的重点可不是讨论缓存的，我们看到TypeCacheUtil的GetFilteredTypesFromAssemblies返回的了一组类型，而这些就是所有的控制器，所以我们继续追下去。

TypeCacheUtil.cs

以下就是GetFilteredTypesFromAssemblies的代码

我们首先不考虑缓存，认为当前没有缓存。那么我们就可以发现其中通过调用FilterTypesInAssemblies获取到一组类型，然后才通过SaveTypesToCache保存至缓存中。既然我们先查看FilterTypesInAssemblies的实现代码

到这里我们就快看到湖底了，因为我们看到了Assembly，而这段代码则是通过遍历所有的程序集将所有的类添加进typesSoFar中，然后在return部分通过TypeIsPublicClass过滤一遍，这个时候只会剩下公开的，非纯虚的类了，而predicate则是在ControllerTypeCache中调用GetFilteredTypesFromAssemblies方法时传入的委托，可以见如下所示的图