ASP.NET Web API Selfhost宿主環境中管道、路由
首先我們先來看個示意圖,大概的描述了在SelfHost宿主環境中管道形態。
圖1
因為在WebHost宿主環境中ASP.NET Web API的管道請求接收以及響應的返回最后都是由ASP.NET來包辦的(下一篇中講解),而在SelfHost宿主環境中就苦逼了,沒有那么簡單了。
我們按照圖1中示意的來講解,首先在SelfHost宿主環境中的項目啟動之后(當然項目要使用Web API框架的),會有一個HttpBinding對象(System.Web.Http.SelfHost.Channels),那這個 HttpBinding類型的對象是干嘛的呢?Httpbinding對象對應著一些個BindingElement對象,而這些 BindingElement又各自生成對應的管道層監聽器,這樣就如圖1中所示的那樣,現在我們看一下如下的示例代碼,看看HttpBinding到底 對應著哪些BindingElement對象。
示例代碼1-1
public class HttpBinding : Binding, IBindingRuntimePreferences { public HttpBinding() { this.Initialize(); } private void Initialize() { this._security = new HttpBindingSecurity(); this._httpTransportBindingElement = new HttpTransportBindingElement(); this._httpTransportBindingElement.ManualAddressing = true; this._httpsTransportBindingElement = new HttpsTransportBindingElement(); this._httpsTransportBindingElement.ManualAddressing = true; this._httpMessageEncodingBindingElement = new HttpMessageEncodingBindingElement(); } }
在示例代碼1-1中我們可以清楚的看到在HttpBinding對象的構造函數中分別的對幾種BindingElement進行了實例化賦值,我們 只對其中的HttpTransportBindingElement和HttpMessageEncodingBindingElement進行講解也就 是圖1中所示的那樣。
HttpTransportBindingElement對象的主要職責就是生成相對應的管道監聽器,這里對應的就是 IChannelListener<TChannel>泛型類型了,而生成好對應的管道監聽器之后,監聽器之后會開始監聽與之對應的管道層, 與HttpTransportBindingElement對象以及監聽器對應的也就是TransprotChannel管道層了,它負責請求消息的接收 和響應消息的發送。
HttpMessageEncodingBindingElement類型的對象所做操作同 HttpTransportBindingElement類型一致,都是先要生成對應的管道監聽器,在這里與之對應的就是 HttpMessageEncodingChannelListener類型,在監聽器生成好之后也會去監聽對應的EncodingChannel管道 層,而EncodingChannel管道層主要的作用就是將請求信息封裝為HttpMessage類型的消息對象,之后由HttpMessage消息對 象進入ASP.NET Web API框架的管道系統中。
上面說的是在請求未到達ASP.NET Web API框架的管道系統中的時候在外部的一些處理和操作,下面我們就要說明一下內部,在上篇的《ASP.NET Web API 管道模型》篇幅中有示例代碼演示過在SelfHost環境下管道的注冊,我們這里看一下在SelfHost環境中Web API框架自身的管道系統里的對象的一些類型。
HttpSelfHostServer消息處理程序(實現類-管道頭)System.Web.Http.SelfHost
public sealed class HttpSelfHostServer : HttpServer { public HttpSelfHostServer(HttpSelfHostConfiguration configuration); public HttpSelfHostServer(HttpSelfHostConfiguration configuration, HttpMessageHandler dispatcher); public Task CloseAsync(); protected override void Dispose(bool disposing); public Task OpenAsync(); }
可以看到HttpSelfHostServer類型繼承自HttpServer,在上篇中我們也就提到過HttpServer是繼承自 DelegatingHandler抽象類型的消息處理程序基類,DelegatingHandler與HttpMessageHandler的不同之處 就是多了個指向下一個處理程序的引用,當然了作為一個管道系統中第一個消息處理程序必須是要有指向下一個處理程序引用的這么一個標識,這樣是合理的。我們 再看HttpSelfHostServer類型的構造函數的參數類型。
HttpSelfHostConfiguration類型是繼承自HttpConfiguration類型的,在上篇中我們也說 過,HttpConfiguration中可以配置管道中的大多數信息,這個大家可以自己去看一下。在重載構造函數中有了第二個構造函數參 數,HttpMessageHandler類型的參數,在默認使用HttpSelfHostServer的時候假使不使用這個重載的構造函數,那么在 HttpSelfHostServer實例化的之前先實例化之前,其基類HttpServer的構造函數開始執行,所以在看下HttpServer類型的 構造函數的時候我們可以看到這里默認設置的HttpMessageHandler類型的參數到底是什么樣子的。
public HttpServer() : this(new HttpConfiguration()) { } public HttpServer(HttpMessageHandler dispatcher) : this(new HttpConfiguration(), dispatcher) { } public HttpServer(HttpConfiguration configuration) : this(configuration, new HttpRoutingDispatcher(configuration)) { } public HttpServer(HttpConfiguration configuration, HttpMessageHandler dispatcher) { this._initializationLock = new object(); if (configuration == null) { throw System.Web.Http.Error.ArgumentNull("configuration"); } if (dispatcher == null) { throw System.Web.Http.Error.ArgumentNull("dispatcher"); } this._dispatcher = dispatcher; this._configuration = configuration; }
這里大家可以清楚的看到是HttpRoutingDispatcher類型作為管道的最后一個處理程序的類型,對于這個類型以及詳細的信息,在下面的路由小節中會有說明。
ASP.NET Web API SelfHost宿主環境路由
對于路由的其他知識這里就不說了,就是簡要的提一下在SelfHost中路由、管道的一些細節。
圖2
這里要詳細說明的就是HttpRoutingDispatcher類型中的SendAsync()方法,看下源碼中的實現這樣更清楚。
public class HttpRoutingDispatcher : HttpMessageHandler { // Fields private readonly HttpConfiguration _configuration; private readonly HttpMessageInvoker _defaultInvoker; // Methods public HttpRoutingDispatcher(HttpConfiguration configuration) : this(configuration, new HttpControllerDispatcher(configuration)) { } protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken) { IHttpRouteData routeData; if (!request.Properties.TryGetValue<IHttpRouteData>(HttpPropertyKeys.HttpRouteDataKey, out routeData)) { routeData = this._configuration.Routes.GetRouteData(request); if (routeData == null) { return TaskHelpers.FromResult<HttpResponseMessage>(request.CreateErrorResponse(HttpStatusCode.NotFound, Error.Format(SRResources.ResourceNotFound, new object[] { request.RequestUri }), SRResources.NoRouteData)); } request.Properties.Add(HttpPropertyKeys.HttpRouteDataKey, routeData); } RemoveOptionalRoutingParameters(routeData.Values); HttpMessageInvoker invoker = (routeData.Route.Handler == null) ? this._defaultInvoker : new HttpMessageInvoker(routeData.Route.Handler, false); return invoker.SendAsync(request, cancellationToken); } }
我們先看一下HttpRoutingDispatcher類型中構造函數,可以看到在定義的構造函數后面緊接著又在實例基類的構造函數,并且第二個 HttpMessageHandler類型的參數為HttpControllerDispatcher實例的對象,這個我們先記住就行了。
下面我們還是回到HttpRoutingDispatcher類型的SendAsync()方法中,首先我們會看到從HttpRequestMessage對象實例的Properties屬性集合中獲取路由數據對象。
在SelfHost的環境下這是獲取不到的,為啥?因為上面以及之前的篇幅中在管道的處理中沒有提到過處理路由并且生成路由數據的。所以這個時候會 根據HttpConfiguration中的HttpRouteCollection類型的屬性Routes,Routes屬性再根據 SendAsync()方法的參數類型為HttpRequestMessage的request信息獲取路由數據對象IHttpRouteData。
在匹配成功獲取到路由數據對象(IHttpRouteData)之后便會添加至HttpRequestMessage對象實例(request)的Properties屬性集合中。
之前對于路由的了解,最后的執行的Handler都是起初定義在路由對象中的,而在實際情況中,我們注冊路由的時候并沒有,假使這種情況就在現在發 生,可以看到routeData.Route.Hander==null這個是成立的,所以執行的是我們先前說過的在構造函數中的 HttpControllerDispatcher類型的實例的SendAsync()方法(實際當中HttpControllerDispatcher 類型被HttpMessageInvoker類型所封裝)。
關鍵字:ASP.NET、管道、路由、
新文章:
- CentOS7下圖形配置網絡的方法
- CentOS 7如何添加刪除用戶
- 如何解決centos7雙系統后丟失windows啟動項
- CentOS單網卡如何批量添加不同IP段
- CentOS下iconv命令的介紹
- Centos7 SSH密鑰登陸及密碼密鑰雙重驗證詳解
- CentOS 7.1添加刪除用戶的方法
- CentOS查找/掃描局域網打印機IP講解
- CentOS7使用hostapd實現無AP模式的詳解
- su命令不能切換root的解決方法
- 解決VMware下CentOS7網絡重啟出錯
- 解決Centos7雙系統后丟失windows啟動項
- CentOS下如何避免文件覆蓋
- CentOS7和CentOS6系統有什么不同呢
- Centos 6.6默認iptable規則詳解