ASP.NET Web API 控制器创建过程(二)

ASP.NET Web API 控制器创建过程(二)

前言

本来这篇随笔应该是在上周就该写出来公布的，因为身体跟不上节奏感冒发烧有心无力，这样的天气感冒发烧生不如死，也真正的体会到了什么叫病来如山倒，病去如抽丝。这两天状态才好了一点，让我理解了什么才是革命的本钱，希望大家也多保重身体。

好了，还是回归主题，对于上一篇的内容解说的仅仅是ASP.NET Web API控制器创建过程中的一个局部知识，在接着上篇内容解说的之前，我会先回想一下上篇的内容，而且在本篇里进行整合，让我们要看到的是一个整个的创建过程。

ASP.NET Web API 控制器创建、激活过程

• ASP.NET Web API 控制器创建过程(一)
• ASP.NET Web API 控制器创建过程(二)

创建、激活过程

图1

在前面的篇幅中我们说过APIController是由HttpControllerDispatcher类型来创建的，这仅仅是表面上的，图1中显示的就是控制器创建的整个过程了，我们先来回想一下上一篇所讲的，不然会认为不连贯，在回想的同一时候也会对图1进行解说。

首先我们来分解图1，能够把图1中分为两个部分，

第一个部分就是HttpConfiguration类型所表示的部分。如图2

图2

先来解释一下HttpConfiguration部分，在HttpConfiguration类型中有两个属性，第一个是ServicesContainer类型的属性Services，第二个就是IDependencyResolver类型的属性DependencyResolver，对于Services属性的类型在上篇中我也说过了，就是一个IoC容器，从HttpConfiguration类型角度来看就是一个依赖注入到HttpConfiguration中的IoC容器，对于DependencyResolver属性来说也差点儿相同就是这个意思了。

仅仅只是Services这个容器中存放的大多都是ASP.NET Web API框架中做一些基础工作的类型。

就好像上篇中说到的，在ASP.NET Web API框架中载入控制器所在程序集的时候我们就是使用自己定义的工作项替换掉了Services容器中的默认工作项：

selfHostServer.Configuration.Services.Replace(typeof(IAssembliesResolver),
                   newCustomAssembliesResolver.LoadSpecifiedAssembliesResolver());

这里从图2中能够看出默认的DefaultAssembliesResolver类型来运行这项工作的。

到这里也就是上个篇幅中的主要内容了。以下我们还是继续分解图1，上面说了第一部分了以下来看第二部分，第二个部分就是HttpControllerDispatcher类型到APIController类型的生成过程，也就是图1了。

首先我们的ASP.NET Web API框架会从HttpConfiguration中的Services容器中获取一个ControllerSelector（控制器选择器），这个控制器选择器呢相应的类型大家从图2中也能够看到，图1中也有，非常明了。

那么ControllerSelector主要干什么呢？肯定是选择控制器阿，当然了依据请求选择对应的控制器是主要功能，次要功能是啥？次要功能是生成控制器缓存，不然从哪选阿对不。在ASP.NET MVC框架中控制器缓存是存在xml文件里的，如今非常好奇在ASP.NET Web API框架中控制器缓存是什么样的存储方式呢？

我们就来看一下控制器选择器的次要功能。

控制器选择器次要功能

首先我们先说明一下缓存的类型为ConcurrentDictionary<string, HttpControllerDescriptor>类型，就是一个一一相应的键值队，string表示着控制器名称，而HttpControllerDescriptor表示着相应控制器的控制器描写叙述类型，这个类型非常重要稍后再说，我们先要了解ConcurrentDictionary<string, HttpControllerDescriptor>缓存的由来。

首先在我们控制器选择器实例化的时候，在控制器选择器的构造函数中已经使用了延迟载入技术对控制器缓存进行了创建，详细的创建过程能够在图1看到，是由DefaultAssembliesResolver类型（或者是我们自己定义的工作项）载入指定的程序集，而且交由DefaultHttpControllerTypeResolver类型依据ASP.NET Web API框架中默认的搜索过滤条件返回载入程序集中的全部符合条件的控制器类型（ControllerTypes），来看演示样例。

所用项目结构还是上个篇幅的演示样例：

图3

图4

在图4中我们额外定义了一些控制器类型，然后在SelfHost端定义例如以下演示样例代码：

代码1-1

        staticvoidWriterControllerTypeMessage(HttpSelfHostServerselfHostServer)
        {

            ICollection<Type>types=selfHostServer.Configuration.Services.GetHttpControllerTypeResolver().GetControllerTypes(selfHostServer.Configuration.Services.GetAssembliesResolver());
            foreach (Typetypeintypes)
            {
                Console.WriteLine(type.Namespace+"_______"+type.Name);
            }
        }

而且在注冊端调用此静态函数：

using (HttpSelfHostServerselfHostServer=newHttpSelfHostServer(selfHostConfiguration))
            {
                selfHostServer.Configuration.Routes.MapHttpRoute(
                    "DefaultApi", "api/{controller}/{id}", new { id=RouteParameter.Optional });

                selfHostServer.Configuration.Services.Replace(typeof(IAssembliesResolver),
                    newCustomAssembliesResolver.LoadSpecifiedAssembliesResolver());

                WriterControllerTypeMessage(selfHostServer);

                selfHostServer.OpenAsync();
                Console.WriteLine("server端服务监听已开启");
                Console.Read();
            }

结果如图5：

图5

在我们获取了ControllerTypes过后了，ASP.NET Web API框架中有个HttpControllerTypeCache类型的对象就藏不住了，之前的一些操作都是由HttpControllerTypeCache类型去处理的，而在HttpControllerTypeCache获取了ControllerTypes过后就要做一个非常重要的工作了，就是对ControllerTypes进行分组操作最后返回一个Dictionary<string, ILookup<string,
Type>>类型的对象，就拿上面的演示样例来说吧，最后经过分组后的Dictionary<string, ILookup<string, Type>>类型值应该是：

Writer-->NameSpaceControllerOne->WriterController

NameSpaceControllerTwo->WriterController

Read-->NameSpaceControllerOne->ReadController

WriterAndRead-->NameSpaceControllerThree->WriterAndReadController

Product-->WebAPIController->ProductController

这个时候的值并非终于的缓存类型，而是通过我们的控制器选择器依据HttpControllerTypeCache类型所生成的Dictionary<string,ILookup<string, Type>>类型值来生成ConcurrentDictionary<string, HttpControllerDescriptor>缓存类型，还是依据上面的演示样例，我们看一下最后生成的缓存类型值。

改动1-1例如以下演示样例代码：

代码1-2

staticvoidWriterControllerTypeMessage(HttpSelfHostServerselfHostServer)
        {

            ICollection<Type>types=selfHostServer.Configuration.Services.GetHttpControllerTypeResolver().GetControllerTypes(selfHostServer.Configuration.Services.GetAssembliesResolver());
            foreach (Typetypeintypes)
            {
                Console.WriteLine(type.Namespace+"_______"+type.Name);
            }

            //Dictionary<string,ILookup<string, Type>> controllertypecache = types.GroupBy<Type,string>(t => t.Name,StringComparer.OrdinalIgnoreCase).ToDictionary<IGrouping<string,Type>, string, ILookup<string, Type>>
            //        (g => g.Key,
            //        g => g.ToLookup<Type,string>(t => (t.Namespace ?? string.Empty),StringComparer.OrdinalIgnoreCase), StringComparer.OrdinalIgnoreCase);

            //foreach(var value in controllertypecache)
            //{
            //    foreach (var val in value.Value)
            //    {

            //    }
            //}

            IDictionary<string, HttpControllerDescriptor>mapping=selfHostServer.Configuration.Services.GetHttpControllerSelector().GetControllerMapping();

            foreach (varmeginmapping)
            {
                Console.WriteLine("ControllerName:"+meg.Key+".ControllerTypeName:"+meg.Value.ControllerType.Name);
            }

        }

结果如图6：

图6

（在代码1-2中凝视掉的部分就是能够查看对ControllerTypes进行分组操作返回Dictionary<string, ILookup<string, Type>>类型的值）。

控制器选择器主要功能

次要功能看完之后，主要功能想必大家也是非常明了吧，在有了控制器缓存对象过后，控制器选择器则会依据HttpRequestMessage对象中的路由数据对象获取控制器名称，然后从缓存中获取到相应的HttpControllerDescriptor类型实例。

详细生成工作

在获取到了HttpControllerDescriptor类型实例过后生成IHttpController的工作就变得非常easy了，还是从HttpConfiguration中的Services容器中获得相应的负责控制器生成激活的工作项，在图1中能够明白的看出是DefaultHttpControllerActivator类型，在DefaultHttpControllerActivator类型工作的时候它会从HttpConfiguration中获取DependencyResolver属性相应的容器，假设这里的情况不满足才会调用后面的TypeActivator来生成激活IHttpController(通过反射)。

作者：金源

出处：http://blog.csdn.net/jinyuan0829

本文版权归作者和CSDN共同拥有，欢迎转载，但未经作者允许必须保留此段声明，且在文章页面