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

      利用少有的空余时间，详细的浏览了下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背后的源码是什么样的

        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");
            }
            //这里的MvcRouteHandler就是一个重要的切入点
            Route route = new Route(url, new MvcRouteHandler())
            {
                Defaults = new RouteValueDictionary(defaults),
                Constraints = new RouteValueDictionary(constraints),
                DataTokens = new RouteValueDictionary()
            };
            //而这里的DataTokens仅仅只是作为附加的参数
            //作为后面搜索控制器时的一个条件
            if ((namespaces != null) && (namespaces.Length > 0))
            {
                route.DataTokens["Namespaces"] = namespaces;
            }
            routes.Add(name, route);
            return route;
        }

 

 

这个方法是对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方法时传入的委托，可以见如下所示的图

而这个方法的具体代码如下

呵呵就是判断这个类型是否是Controller结尾，并且是否实现了Icontroller接口，这样我们就获取到了所有的控制器了。

 

细心的读者会发现FilterTypesInAssemblies方法中buildManager.GetReferencedAssemblies();到底是调用的什么类型呢？以及什么方法呢？下面我发个图，大家就能够明白了

 

小结

      到此为止我们基本上就探索完了，如何按照路由参数的名称查找到具体的控制器这个任务就留给读者了，因为已经很明了，本身查找出来的控制器类型就是按照名字、类型保存进字典的，获取就非常简单了。