您好,登錄后才能下訂單哦!
前言
前面的幾個篇幅對Web API中的路由和管道進行了簡單的介紹并沒有詳細的去說明一些什么,然而ASP.NET Web API這個框架由于宿主環境的不同在不同的宿主環境中管道中的實現機制和路由的處理方式有著很大的不同,所以我會將對應不同的宿主環境來分別的做出簡單的講解。
ASP.NET Web API 開篇介紹示例
ASP.NET Web API 路由對象介紹
ASP.NET Web API 管道模型
ASP.NET Web API selfhost宿主環境中管道、路由
ASP.NET Web API webhost宿主環境中管道、路由
首先我們先來看個示意圖,大概的描述了在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
publicclassHttpBinding : Binding, IBindingRuntimePreferences { publicHttpBinding() { this.Initialize(); } privatevoidInitialize() { this._security=newHttpBindingSecurity(); this._httpTransportBindingElement=newHttpTransportBindingElement(); this._httpTransportBindingElement.ManualAddressing=true; this._httpsTransportBindingElement=newHttpsTransportBindingElement(); this._httpsTransportBindingElement.ManualAddressing=true; this._httpMessageEncodingBindingElement=newHttpMessageEncodingBindingElement(); } }
在示例代碼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
publicsealedclassHttpSelfHostServer : HttpServer { publicHttpSelfHostServer(HttpSelfHostConfigurationconfiguration); publicHttpSelfHostServer(HttpSelfHostConfigurationconfiguration, HttpMessageHandlerdispatcher); publicTaskCloseAsync(); protectedoverridevoidDispose(booldisposing); publicTaskOpenAsync(); }
可以看到HttpSelfHostServer類型繼承自HttpServer,在上篇中我們也就提到過HttpServer是繼承自DelegatingHandler抽象類型的消息處理程序基類,DelegatingHandler與HttpMessageHandler的不同之處就是多了個指向下一個處理程序的引用,當然了作為一個管道系統中第一個消息處理程序必須是要有指向下一個處理程序引用的這么一個標識,這樣是合理的。我們再看HttpSelfHostServer類型的構造函數的參數類型。
HttpSelfHostConfiguration類型是繼承自HttpConfiguration類型的,在上篇中我們也說過,HttpConfiguration中可以配置管道中的大多數信息,這個大家可以自己去看一下。在重載構造函數中有了第二個構造函數參數,HttpMessageHandler類型的參數,在默認使用HttpSelfHostServer的時候假使不使用這個重載的構造函數,那么在HttpSelfHostServer實例化的之前先實例化之前,其基類HttpServer的構造函數開始執行,所以在看下HttpServer類型的構造函數的時候我們可以看到這里默認設置的HttpMessageHandler類型的參數到底是什么樣子的。
publicHttpServer() : this(newHttpConfiguration()) { } publicHttpServer(HttpMessageHandlerdispatcher) : this(newHttpConfiguration(), dispatcher) { } publicHttpServer(HttpConfigurationconfiguration) : this(configuration, newHttpRoutingDispatcher(configuration)) { } publicHttpServer(HttpConfigurationconfiguration, HttpMessageHandlerdispatcher) { this._initializationLock=newobject(); if (configuration==null) { throwSystem.Web.Http.Error.ArgumentNull("configuration"); } if (dispatcher==null) { throwSystem.Web.Http.Error.ArgumentNull("dispatcher"); } this._dispatcher=dispatcher; this._configuration=configuration; }
這里大家可以清楚的看到是HttpRoutingDispatcher類型作為管道的最后一個處理程序的類型,對于這個類型以及詳細的信息,在下面的路由小節中會有說明。
對于路由的其他知識這里就不說了,就是簡要的提一下在SelfHost中路由、管道的一些細節。
圖2
這里要詳細說明的就是HttpRoutingDispatcher類型中的SendAsync()方法,看下源碼中的實現這樣更清楚。
publicclassHttpRoutingDispatcher : HttpMessageHandler { //Fields privatereadonlyHttpConfiguration_configuration; privatereadonlyHttpMessageInvoker_defaultInvoker; //Methods publicHttpRoutingDispatcher(HttpConfigurationconfiguration) : this(configuration, newHttpControllerDispatcher(configuration)) { } protectedoverrideTask<HttpResponseMessage>SendAsync(HttpRequestMessagerequest, CancellationTokencancellationToken) { IHttpRouteDatarouteData; if (!request.Properties.TryGetValue<IHttpRouteData>(HttpPropertyKeys.HttpRouteDataKey, outrouteData)) { routeData=this._configuration.Routes.GetRouteData(request); if (routeData==null) { returnTaskHelpers.FromResult<HttpResponseMessage>(request.CreateErrorResponse(HttpStatusCode.NotFound, Error.Format(SRResources.ResourceNotFound, newobject[] { request.RequestUri }), SRResources.NoRouteData)); } request.Properties.Add(HttpPropertyKeys.HttpRouteDataKey, routeData); } RemoveOptionalRoutingParameters(routeData.Values); HttpMessageInvokerinvoker= (routeData.Route.Handler==null) ?this._defaultInvoker : newHttpMessageInvoker(routeData.Route.Handler, false); returninvoker.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類型所封裝)。
而HttpControllerDispatcher類型就跟Web API控制器有關了,這里就不提前說了,后面一定會講到。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。