ASP.NET MVC Controller激活系统详解：默认实现

Controller激活系统最终通过注册的ControllerFactory创建相应的Conroller对象，如果没有对ControllerFactory类型或者类型进行显式注册（通过调用当前ControllerBuilder的SetControllerFactory方法），默认使用的是一个DefaultControllerFactory对象，我们现在就来讨论实现在DefaultControllerFactory类型中的默认Controller激活机制。

目录
一、Controller类型的解析
    实例演示：创建一个自定义ControllerFactory模拟Controller默认激活机制
二、 Controller类型的缓存
三、 Controller的释放
四、会话状态行为的控制

一、Controller类型的解析

激活目标Controller对象的前提是能够正确解析出对应的Controller类型。对于DefaultControllerFactory来，用于解析目标Controller类型的信息包括：通过与当前请求匹配的路由对象生成的RouteData（其中包含Controller的名称和命名空间）和包含在当前ControllerBuilder中的命名空间。很对读者可以首先想到的是通过Controller名称得到对应的类型，并通过命名空间组成Controller类型的全名，最后遍历所有程序集以此名称去加载相应的类型即可。

这貌似一个不错的解决方案，实际上则完全不可行。不要忘了作为请求地址URL一部分的Controller名称是不区分大小写的，而类型名称则是区分大小的；不论是注册路由时指定的命名空间还是当前ControllerBuilder的默认命名空间，有可能是包含统配符（*）。由于我们不能通过给定的Controller名称和命名空间得到Controller的真实类型名称，自然就不可能通过名称去解析Controller的类型了。

ASP.NET MVC的Controller激活系统反其道而行之。它先遍历通过BuildManager的静态方法GetReferencedAssemblies方法得到的编译Web应用所使用的程序集，通过反射得到所有实现了接口IController的类型，最后通过给定的Controller的名称和命名空间作为匹配条件在这个预先获取的类型列表中得到目标Controller的类型。

实例演示：创建一个自定义ControllerFactory模拟Controller默认激活机制

为了让读者对默认采用的Controller激活机制，尤其是Controller类型的解析机制有一个深刻的认识，我们通过一个自定义的ControllerFactory来模拟其中的实现。由于我们采用反射的方式来创建Controller对象，所以我们将该自定义ControllerFactory起名为ReflelctionControllerFactory。[源代码从这里下载]

 1: public class ReflelctionControllerFactory : IControllerFactory

 10: controllerTypes.AddRange(assembly.GetTypes().Where(type = typeof(IController).IsAssignableFrom(type)));

 14: public IController CreateController(RequestContext requestContext, string controllerName)

 16: Type controllerType = this.GetControllerType(requestContext.RouteData, controllerName);

 24: private static bool IsNamespaceMatch(string requestedNamespace, string targetNamespace)

 26: if (!requestedNamespace.EndsWith(".*", StringComparison.OrdinalIgnoreCase))

 28: return string.Equals(requestedNamespace, targetNamespace, StringComparison.OrdinalIgnoreCase);

 30: requestedNamespace = requestedNamespace.Substring(0, requestedNamespace.Length - ".*".Length);

 31: if (!targetNamespace.StartsWith(requestedNamespace, StringComparison.OrdinalIgnoreCase))

 35: return ((requestedNamespace.Length == targetNamespace.Length) || (targetNamespace[requestedNamespace.Length] == .));

 38: private Type GetControllerType(IEnumerable string namespaces, Type[] controllerTypes)

 47: default: throw new InvalidOperationException("Multiple types were found that match the requested controller name.");

 51: protected virtual Type GetControllerType(RouteData routeData, string controllerName)

如上面的代码片断所示，ReflelctionControllerFactory具有一个静态的controllerTypes字段由于保存所有Controller的类型。在静态构造函数中，我们调用BuildManager的GetReferencedAssemblies方法得到所有用于编译Web应用的程序集，并从中得到所有实现了IController接口的类型，这些类型全部被添加到通过静态字段controllerTypes表示的类型列表。

Controller类型的解析实现在受保护的GetControllerType方法中，在用于最终激活Controller对象的CreateController方法中，我们通过调用该方法得到与指定RequestContext和Controller名称相匹配的Controller类型，最终通过调用Activator的静态方法CreateInstance根据该类型创建相应的Controller对象。如果不能找到匹配的Controller类型（GetControllerType方法返回Null），则抛出一个HTTP状态为404的HttpException。

ReflelctionControllerFactory中定义了两个辅助方法，IsNamespaceMatch用于判断Controller类型真正的命名空间是否与指定的命名空间（可能包含统配符）相匹配，在进行字符比较过程中是忽略大小写的。私有方法GetControllerType根据指定的命名空间列表和类型名称匹配的类型数组得到一个完全匹配的Controller类型。如果得到多个匹配的类型，直接抛出InvalidOperation异常，并提示具有多个匹配的Controller类型；如果找不到匹配类型，则返回Null。

在如下所示的用于解析Controller类型的GetControllerType方法中，我们从预先得到的所有Controller类型列表中筛选出类型名称与传入的Controller名称相匹配的类型。我们首先通过路由对象的命名空间对 得到的类型列表进行进一步筛选，如果能够找到一个唯一的类型，则直接将其作为Controller的类型返回。为了确定是否采用后备命名空间对Controller类型进行解析，我们从作为参数参数的RouteData对象的DataTokens中得到获取一个Key为“UseNamespaceFallback”的元素，如果该元素存在并且值为False，则直接返回Null。

如果RouteData的DataTokens中不存在这样一个UseNamespaceFallback元素，或者它的值为True，则首先里当前ControllerBuilder的默认命名空间列表进一步对Controller类型进行解析，如果存在唯一的类型则直接当作目标Controller类型返回。如果通过两组命名空间均不能得到一个匹配的ControllerType，并且只存在唯一一个与传入的Controller名称相匹配的类型，则直接将该类型作为目标Controller返回。如果这样的类型具有多个，则直接抛出InvalidOperationException异常。

 4: protected virtual Type GetControllerType (RouteData routeData, string controllerName)

 7: var types = controllerTypes.Where(type = string.Compare(controllerName + "Controller", type.Name, true) == 0).ToArray();

 14: var namespaces = routeData.DataTokens["Namespaces"] as IEnumerable string 

 26: useNamespaceFallback = (bool)(routeData.DataTokens["UseNamespaceFallback"]);

 36: contrllerType = this.GetControllerType(ControllerBuilder.Current.DefaultNamespaces, types);

 49: throw new InvalidOperationException("Multiple types were found that match the requested controller name.");

二、 Controller类型的缓存

为了避免通过遍历所有程序集对目标Controller类型的解析，ASP.NET MVC对解析出来的Controller类型进行了缓存以提升性能。与针对用于Area注册的AreaRegistration类型的缓存类似，Controller激活系统同样采用基于文件的缓存策略，而用于保存Controller类型列表的名为MVC-ControllerTypeCache.xml的文件保存在ASP.NET的临时目录下面。具体的路径如下，其中第一个针对寄宿于IIS中的Web应用，后者针对直接通过Visual Studio Developer Server作为宿主的应用。而用于保存所有AreaRegistration类型列表的MVC-AreaRegistrationTypeCache.xml文件也保存在这个目录下面。

%Windir%\Microsoft.NET\Framework\v{version}\Temporary ASP.NET Files\{appname}\...\...\UserCache\ %Windir%\Microsoft.NET\Framework\v{version}\Temporary ASP.NET Files\root\...\...\UserCache\

对针对Web应用被启动后的第一个请求时，Controller激活系统会读取这个用于缓存所有Controller类型列表的ControllerTypeCache.xml文件并反序列化成一个List Type 对象。只有在该列表为空的时候才会通过遍历程序集和反射的方式得到所有实现了接口IController的公有类型，而被解析出来的Controller类型重写被写入ControllerTypeCache.xml文件中。这个通过读取缓存文件或者重新解析出来的Controller类型列表被保存到内容中，在Web应用活动期间内被Controller激活系统所用。

下面的XML片断反映了这个用于Controller类型列表缓存的ControllerTypeCache.xml文件的结构，我们可以看出它包含了所有的Controller类型的全名和所在的程序集和托管模块信息。

 2: !--This file is automatically generated. Please do not modify the contents of this file.-- 

 3: typeCache lastModified="3/22/2012 1:18:49 PM" mvcVersionId="80365b23-7a1d-42b2-9e7d-cc6f5694c6d1" 

 4: assembly name="Artech.Admin, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" 

 10: assembly name="Artech.Portal, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" 

三、 Controller的释放

作为激活Controller对象的ControllerFactory不仅仅用于创建目标Controller对象，还具有两个额外的功能，即通过ReleaseController方法对激活的Controller对象进行释放和回收，以及通过GetControllerSessionBehavior返回用于控制当前会话状态行为的SessionStateBehavior枚举。

对于默认使用DefaultControllerFactory来说，针对Controller对象的释放操作很简单：如果Controller类型实现了IDisposable接口，则直接调用其Dispose方法即可；否则直接忽略。我们将这个逻辑也实现在了我们自定义的ReflelctionControllerFactory中。

四、会话状态行为的控制

至于用于返回SessionStateBehavior枚举的GetControllerSessionBehavior方法来说，在默认的情况下的返回值为SessionStateBehavior.Default。通过前面的介绍我们知道在这种情况下具体的会话状态行为取决于创建的HttpHandler所实现的标记接口。对于ASP.NET MVC应用来说，默认用于处理请求的HttpHandler是一个叫做MvcHandler的对象，如下面的代码片断所示，HttpHandler实现了IRequiresSessionState接口，意味着默认情况下会话状态是可读写的（相当于SessionStateBehavior.Requried）。

不过我们可以通过在Controller类型上应用SessionStateAttribute特性来具体控制会话状态行为。如下面的代码片断所示，SessionStateAttribute具有一个SessionStateBehavior类型的只读属性Behavior用于返回具体行为设置的会话状态行为选项，该属性是在构造函数中被初始化的。

 1: [AttributeUsage(AttributeTargets.Class, AllowMultiple = false, Inherited = true)]

也就是说DefaultControllerFactory会通过解析出来的Controller类型得到应用在上面的SessionStateAttribute特性，如果这样的特性存在则直接返回它的Behavior属性所表示的SessionStateBehavior枚举；如果不存在则返回SessionStateBehavior.Default，具体的逻辑反映在我们自定义的ReflelctionControllerFactory的GetControllerSessionBehavior方法中。

 4: public SessionStateBehavior GetControllerSessionBehavior(RequestContext requestContext, string controllerName)

 6: Type controllerType = this.GetControllerType(requestContext.RouteData, controllerName);

 11: SessionStateAttribute attribute = controllerType.GetCustomAttributes(true).OfType SessionStateAttribute ()

 13: attribute = attribute ?? new SessionStateAttribute(SessionStateBehavior.Default);

微信公众账号：大内老A
微博：www.weibo.com/artech
如果你想及时得到个人撰写文章以及著作的消息推送，或者想看看个人推荐的技术资料，可以扫描左边二维码（或者长按识别二维码）关注个人公众号（原来公众帐号蒋金楠的自媒体将会停用）。
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。 原文链接

基于Asp.Net Mvc开发的个人博客系统 一个基于Mvc 5构建的简单、代码层级分明的开源个人博客系统。前端美观大气、后台采用RightControl .NET通用角色权限系统，开发简单、效率高。网站配置采用XML配置，灵活可以根据自己是需求进行个性化配置。系统功能完备，完全可以满足需求，基本不用二次开发，非常使用程序员的个人博客。
ASP.NET Core 使用 JWT 搭建分布式无状态身份验证系统 原文:ASP.NET Core 使用 JWT 搭建分布式无状态身份验证系统 升级到 Asp.Net Core 2.0 (2017/08/29 更新) 为什么使用 Jwt 最近，移动开发的劲头越来越足，学校搞的各种比赛都需要用手机 APP 来撑场面，所以，作为写后端的，很有必要改进一下以往的基于 ...