asp.net Web API 控制器創建過程(一)

ASP.NET Web API 控制器創建過程(一)

前言

在前面對管道、路由有了基礎的了解過后，本篇將帶大家一起學習一下在ASP.NET Web API中控制器的創建過程，這過程分為幾個部分下面的內容會為大家講解第一個部分，也是ASP.NET Web API框架跟ASP.NET MVC框架實現上存在不同的一部分。

ASP.NET Web API 控制器創建、激活過程

• ASP.NET Web API 控制器創建過程(一)
• ASP.NET Web API 控制器創建過程(二)
• 未完待續

環境描述、問題的發現

在項目運用中，我們大多數會把控制器部分從主程序抽離出來放置單獨的項目中，這種情況下在使用ASP.NET MVC框架的項目環境中是不會有什么問題的，因為MVC框架在創建控制器的時候會加載當前主程序引用的所有程序集并且按照執行的搜索規則（公共類型、實現IController的）搜索出控制器類型并且緩存到xml文件中。而這種方式如果在使用了默認的ASP.NET Web API框架環境下就會有一點點的問題，這里就涉及到了Web API框架的控制器創建過程中的知識。來看一下簡單的示例。

（示例還是《ASP.NET Web API 開篇介紹示例》中的示例，不過做了略微的修改，符合上述的情況。）

我們還是在SelfHost環境下做示例，來看SelfHost環境下服務端配置：

示例代碼1-1

    class PRogram    {        static void Main(string[] args)        {            HttpSelfHostConfiguration selfHostConfiguration =                new HttpSelfHostConfiguration("http://localhost/selfhost");            using (HttpSelfHostServer selfHostServer = new HttpSelfHostServer(selfHostConfiguration))            {                selfHostServer.Configuration.Routes.MapHttpRoute(                    "DefaultApi", "api/{controller}/{id}", new { id = RouteParameter.Optional });                selfHostServer.OpenAsync();                Console.WriteLine("服務器端服務監聽已開啟");                Console.Read();            }        }    }

代碼1-1就是引用《ASP.NET Web API 開篇介紹示例》中的示例，在示例SelfHost項目中定義了API控制器，在這里我們需要把它注釋掉，并且創建新的類庫項目命名為WebAPIController，并且引用System.Web.Http.dll程序集和Common程序集，然后再定義個API控制器，也就是把原先在SelfHost項目中的控制器移動到新建的類庫項目中。

示例代碼1-2

using System.Web.Http;using Common;namespace WebAPIController{    public class ProductController : ApiController    {        private static List<Product> products;        static ProductController()        {            products = new List<Product>();            products.AddRange(                new Product[]                 {                    new Product(){ ProductID="001", ProductName="牙刷",ProductCategory="洗漱用品"},                    new Product(){ ProductID="002", ProductName="《.NET框架設計—大型企業級應用框架設計藝術》", ProductCategory="書籍"}                });        }        public IEnumerable<Product> Get(string id = null)        {            return from product in products where product.ProductID == id || string.IsNullOrEmpty(id) select product;        }        public void Delete(string id)        {            products.Remove(products.First(product => product.ProductID == id));        }        public void Post(Product product)        {            products.Add(product);        }        public void Put(Product product)        {            Delete(product.ProductID);            Post(product);        }    }}

這個時候還要記得把SelfHost項目添加WebAPIController項目的引用，要保持跟MVC項目的環境一樣，然后我們在運行SelfHost項目，等待監聽開啟過后再使用瀏覽器請求服務會發現如下圖所示的結果。

圖1

看到圖1中的顯示問題了吧，未找到匹配的控制器類型。如果是MVC項目則不會有這樣的問題，那么問題出在哪呢？實現方式的差異，下面就為大家來解釋一下。

解決問題

在上一篇中我們最后的示意圖里可以清晰的看到ASP.NET Web API框架中的管道模型最后是通過HttpControllerDispatcher類型的對象來“生成”的APIController。我們現在就來看一下HttpControllerDispatcher類型的定義。

示例代碼1-3

    public class HttpControllerDispatcher : HttpMessageHandler    {        // Fields        private readonly HttpConfiguration _configuration;        private IHttpControllerSelector _controllerSelector;        // Methods        public HttpControllerDispatcher(HttpConfiguration configuration);        private static HttpResponseMessage HandleException(HttpRequestMessage request, Exception exception);        protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken);        private Task<HttpResponseMessage> SendAsyncInternal(HttpRequestMessage request, CancellationToken cancellationToken);        // Properties        public HttpConfiguration Configuration { get; }        private IHttpControllerSelector ControllerSelector { get; }}

從示例代碼1-3中可以看到HttpControllerDispatcher類型繼承自HttpMessageHandler類型，由此可見，通過前面《ASP.NET Web API 管道模型》篇幅的知識我們了解到在ASP.NET Web API管道的最后一個消息處理程序實際是HttpControllerDispatcher類型，在Web API框架調用HttpControllerDispatcher類型的SendAsync()方法時實際是調用了HttpControllerDispatcher類型的一個私有方法SendAsyncInternal()，而APIController就是在這個私有方法中生成的，當然不是由這個私有方法來生成它的。下面我們就來看一下SendAsyncInternal()的基礎實現。

示例代碼1-4

    private Task<HttpResponseMessage> SendAsyncInternal(HttpRequestMessage request, CancellationToken cancellationToken)    {        IHttpRouteData routeData = request.GetRouteData();        HttpControllerDescriptor descriptor = this.ControllerSelector.SelectController(request);        IHttpController controller = descriptor.CreateController(request);    }

代碼1-4很清晰的說明了APIController的生成過程，這只是片面的，這里的代碼并不是全部，我們現在只需關注APIController的生成過程，暫時不去關心它的執行過程。

首先由HttpControllerDispatcher類型中的一個類型為IHttpControllerSelector的屬性ControllerSelector（實則是DefaultHttpControllerSelector類型）根據HttpRequestMessage參數類型來調用IHttpControllerSelector類型里的SelectController()方法，由此獲取到HttpControllerDescriptor類型的變量descriptor，然后由變量descriptor調用它的CreateController()方法來創建的控制器。

說到這里看似一個簡單的過程里面蘊含的知識還是有一點的，我們首先來看ControllerSelector屬性：

示例代碼1-5

    private IHttpControllerSelector ControllerSelector    {        get        {            if (this._controllerSelector == null)            {                this._controllerSelector = this._configuration.Services.GetHttpControllerSelector();            }            return this._controllerSelector;        }    }

這里我們可以看到是由HttpConfiguration類型的變量_configuration中的Servieces（服務容器）來獲取的IHttpControllerSelector類型的對象。那我們獲取到的究竟實例是什么類型的？

到這里先暫停，大家先不用記住上面的一堆廢話中的內容，現在我們來看一下HttpConfiguration這個類型，我們現在只看HttpConfiguration類型，忘掉上面的一切。

示例代碼1-6

    public class HttpConfiguration : IDisposable    {        // Fields        private IDependencyResolver _dependencyResolver;        // Methods        public HttpConfiguration();        public HttpConfiguration(HttpRouteCollection routes);        private HttpConfiguration(HttpConfiguration configuration, HttpControllerSettings settings);        public IDependencyResolver DependencyResolver { get; set; }        public ServicesContainer Services { get; internal set; }    }

在這里我們看到有字段、構造函數和屬性，對于_dependencyResolver字段和對應的屬性我們下面會有講到這里就不說了。這里主要就是說明一下ServicesContainer 類型的Services屬性。對于ServicesContainer類型沒用的朋友可能不太清楚，實際上可以把ServicesContainer類型想象成一個IoC容器，就和IDependencyResolver類型的作用是一樣的，在前面的《C#編程模式之擴展命令》一文中有涉及到ServicesContainer類型的使用，感興趣的朋友可以去看看。

回到主題，在構造函數執行時ServicesContainer類型實例實際是由它的子類DefaultServices類型實例化而來的。而在DefaultServices類型實例化的時候它的構造函數中會將一些服務和具體實現的類型添加到緩存里。

圖2

在圖2中我們現在只需關注第二個紅框中的IHttpControllerSelector對應的具體服務類型是DefaultHttpControllerSelector類型。

現在我們再來看代碼1-5中的GetHttpControllerSelector()方法，它是有ServicesExtensions擴展方法類型來實現的。

好了現在大家的思緒可以回到代碼1-4中，現在我們知道是由DefaultHttpControllerSelector類型的SelectController()方法來生成HttpControllerDescriptor類型的。暫時不用管HttpControllerDescriptor類型，我們先來看SelectController()方法中的實現細節。

示例代碼1-7

public virtual HttpControllerDescriptor SelectController(HttpRequestMessage request)    {        HttpControllerDescriptor descriptor;        string controllerName = this.GetControllerName(request);        if (this._controllerInfoCache.Value.TryGetValue(controllerName, out descriptor))        {            return descriptor;        }    }

這里可以看到controllerName是由路由數據對象RouteData來獲取的，然后由_controllerInfoCache變量根據控制器名稱獲取到HttpControllerDescriptor實例，這里HttpControllerDescriptor實例我們暫且不管，后面的篇幅會有講到。

重點是我們看一下_controllerInfoCache變量中的值是怎么來的？是從HttpControllerTypeCache類型的Cache屬性值而來。而Cache的值則是根據HttpControllerTypeCache類型的中的InitializeCache()方法得來的，我們看下實現。

實例代碼1-8

    private Dictionary<string,