ASP.NET Web API標准的“管道式”設計

 　　ASP.NET Web API的核心框架是一個消息處理管道，這個管道是一組HttpMessageHandler的有序組合。這是一個雙工管道，請求消息從一端流入並依次經過所有HttpMessageHandler的處理。在另一端，目標HttpController被激活，Action方法被執行，響應消息隨之被生成。響應消息逆向流入此管道，同樣會經過逐個HttpMessageHandler的處理。這是一個獨立於寄宿環境的抽象管道，如何實現對請求的監聽與接收，以及將接收的請求傳入消息處理管道進行處理並將管道生成的響應通過網絡回傳給客戶端，這就是Web API寄宿需要解決的問題。

　　目錄

　　一、HttpMessageHandler

　　二、DelegatingHandler

　　三、HttpServer

　　四、HttpRoutingDispatcher

　　五、HttpControllerDispatcher

　　一、HttpMessageHandler

　　ASP.NET Web API的消息處理管道由一組HttpMessageHandler經過“首尾相連”而成，ASP.NET Web API之所以具有較高的可擴展性，主要源於采用的管道式設計。雖然ASP.NET Web API框架旨在實現針對請求的處理和響應的回復，但是采用的處理策略因具體的場景而不同。

　　我們不可能也沒有必要創建一個“萬能”的處理器來滿足所有的請求處理需求，倒不如讓某個處理器只負責某個單一的消息處理功能。在具體的應用場景中，我們可以根據具體的消息處理需求來選擇所需的處理器並組成一個完整的消息處理管道。在這裡這個用於完成某個單一消息處理功能的處理器就是HttpMessageHandler。

　　這裡的“消息處理”具有兩個層面的含義，既包括針對請求消息的處理，還包括針對響應消息的處理。HttpMessageHandler直接或者間接繼承自具有如下定義的抽象類型HttpMessageHandler，該類型定義在命名空間“System.Net.Http”下。ASP.NET Web API通過類型HttpRequestMessage和HttpResponseMessage來表示管道處理的請求消息和響應消息，所以對HttpMessageHandler的定義就很好理解了。

　　1: public abstract class HttpMessageHandler : IDisposable

　　2: {

　　3: public void Dispose();

　　4: protected virtual void Dispose(bool disposing);

　　5: protected abstract Task SendAsync(HttpRequestMessage request, CancellationToken cancellationToken);

　　6: }

　　如上面的代碼片斷所示，抽象類HttpMessageHandler定義了一個受保護的抽象方法SendAsync，這是一個采用針對Task的“並行編程模式”的異步方法，在後續的章節中我們會看到ASP.NET Web API的應用程序接口基本上都采用這樣的定義方式。對於這個SendAsync方法來說，request參數表示傳遞給當前HttpMessageHandler進行處理的請求，這是一個HttpRequestMessage對象。另一個參數cancellationToken是一個用於發送取消操作信號的CancellationToken對象，如果讀者對.NET中的並行編程具有基本了解的話，相信對這個類型不會感到陌生。

　　針對請求消息和響應消息的處理均體現在這個SendAsync方法上。具體來說，針對請求消息的處理直接實現在SendAsync方法中，而針對響應消息的處理則通過其返回的Task對象來完成。由HttpMessageHandler組成的消息處理管道以及請求消息和響應消息在管道中的“流動”基本上可以通過右圖來體現。

　　抽象類HttpMessageHandler實現了IDisposable接口，它按照“標准”的方式實現Dispose方法。如下面的代碼片斷所示，當我們調用Dispose方法的時候，HttpMessageHandler並沒有執行任何資源回收操作。當我們通過繼承這個抽象類自定義HttpMessagHandler的時候，可以將資源回收操作實現在重寫的Dispose方法中。

　　1: public abstract class HttpMessageHandler : IDisposable

　　2: {

　　3: //其他操作

　　4: public void Dispose()

　　5: {

　　6: this.Dispose(true);

　　7: GC.SuppressFinalize(this);

　　8: }

　　9:

　　10: protected virtual void Dispose(bool disposing)

　　11: {}

　　12: }

　　二、DelegatingHandler

　　我們說ASP.NET Web API消息處理管道是通過一組有序的HttpMessagHandler“首尾相連”而成，具體實現“管道串聯”是通過DelegatingHandler這個類型來完成的。顧名思義，DelegatingHandler具有委托功能，當它自己負責的消息處理任務完成之後可以委托另一個HttpMessagHandler進行後續的處理。如果這個被委托的也是一個DelegatingHandler對象，不就可以組成一個委托鏈了嗎?而這個委托鏈不就是由一個個DelegatingHandler組成的消息處理管道嗎?

　　如下面的代碼片斷所示，DelegatingHandler是一個繼承自HttpMessageHandler類的抽象類。上面我們所說的這個被委托的HttpMessagHandler由它的屬性InnerHandler表示。DelegatingHandler重寫了定義在其類的抽象方法SendAsync來調用InnerHandler屬性的同名方法。

　　1: public abstract class DelegatingHandler : HttpMessageHandler

　　2: {

　　3: protected internal override Task SendAsync(HttpRequestMessage request, CancellationToken cancellationToken);

　　4: public HttpMessageHandler InnerHandler get; set; }

　　5: }

　　正如上面所說，如果ASP.NET Web API的消息處理管道均由DelegatingHandler組成(位於管道尾端的HttpMessageHandler除外)，我們就可以根據其InnerHandler獲得對被委托的HttpMessageHandler對象的引用，由此便構成具有如上圖所示的鏈式結構。組成ASP.NET Web API核心框架的消息處理管道就這麼簡單。

　　三、HttpServer

　　一般來說，對於構成ASP.NET Web API消息處理管道的所有HttpMessageHandler來說，除了處於尾端的那一個之外，其余的均為DelegatingHandler，那麼通過InnerHandler屬性維持著“下一個” HttpMessageHandler。作為這個HttpMessageHandler鏈“龍頭”的是一個HttpServer對象，該類型定義在命名空間“System.Web.Http”下。

　　如下面的代碼片斷所示，HttpServer直接繼承自DelegatingHandler。它具有兩個重要的只讀屬性(Configuration和Dispatcher)，我們可以通過前者得到用於配置整個消息處理管道的HttpConfiguration對象，另外一個屬性Dispatcher返回的是處於整個消息處理管道“尾端”的HttpMessageHandler。

　　1: public class HttpServer : DelegatingHandler

　　2: {

　　3: public HttpConfiguration Configuration { get; }

　　4: public HttpMessageHandler Dispatcher { get; }

　　5:

　　6: public HttpServer();

　　7: public HttpServer(HttpMessageHandler dispatcher);

　　8: public HttpServer(HttpConfiguration configuration);

　　9: public HttpServer(HttpConfiguration configuration, HttpMessageHandler dispatcher);

　　10:

　　11: protected override void Dispose(bool disposing);

　　12: protected virtual void Initialize();

　　13: protected override Task SendAsync(HttpRequestMessage request, CancellationToken cancellationToken);

　　14: }

　　HttpServer的Configuration和Dispatcher屬性均可以在相應的構造函數中初始化。如果在構造HttpServer的時候沒有顯式指定這兩個屬性的值(調用默認的無參構造函數創建HttpServer)，在默認情況下會創建一個HttpConfiguration作為Configuration的屬性值，而作為Dispatcher屬性值的則是一個HttpRoutingDispatcher對象，該類型定義在命名空間“System.Web.Http.Dispatcher”下。除此之外。由於HttpConfiguration類型實現了IDisposable接口，所以HttpServer重寫了虛方法Dispose並在該方法中完成了對HttpConfiguration對象的釋放。

　　當HttpServer對象被成功創建之後，對應的消息處理管道的“一頭一尾”已經確定下來。一頭指的就是HttpServer對象本身，一尾指的自然就是通過Dispatcher屬性引用的HttpMessageHandler對象了。ASP.NET Web API框架最大的擴展性就在於我們可以根據具體的消息處理需求來“定制”這個消息處理管道，它允許我們將自定義的HttpMessageHandler按照如左圖所示的方式“安裝”到這一頭一尾之間，但是這些處於“中間位置”的HttpMessageHandler是如何注冊呢?

　　既然整個管道都是由HttpConfiguration進行配置，那麼自定義HttpMessageHandler的注冊自然也可以利用它來完成。如下面的代碼片斷所示，HttpConfiguration具有一個只讀的集合類型的MessageHandlers，需要注冊的HttpMessageHandler需要添加到此集合之中。由於這是一個元素類型為DelegatingHandler的集合，所以我們自定義的HttpMessageHandler必須繼承自DelegatingHandler。

　　1: public class HttpConfiguration : IDisposable

　　2: {

　　3: //其他成員

　　4: public Collection MessageHandlers { get; }

　　5: }

　　通過上面的給出的HttpServer類型定義我們可以看到它具有一個受保護的Initialize