前言
創(chuàng)新互聯(lián)建站于2013年創(chuàng)立,是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司,擁有項(xiàng)目網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè)網(wǎng)站策劃,項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢(mèng)想脫穎而出為使命,1280元昌邑做網(wǎng)站,已為上家服務(wù),為昌邑各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:028-86922220
ASP.NET Web API是一個(gè)獨(dú)立的框架,也有著自己的一套消息處理管道,不管是在WebHost宿主環(huán)境還是在SelfHost宿主環(huán)境請(qǐng)求和響應(yīng)都是從消息管道經(jīng)過(guò)的,這是必經(jīng)之地,本篇就為大家簡(jiǎn)單的介紹一下ASP.NET Web API框架中的管道對(duì)象模型。
ASP.NET Web API路由、管道
l ASP.NET Web API開(kāi)篇介紹示例
l ASP.NET Web API路由對(duì)象介紹
l ASP.NET Web API管道模型
l ASP.NET Web API selfhost宿主環(huán)境中管道、路由
l ASP.NET Web API webhost宿主環(huán)境中管道、路由
管道模型介紹
HttpMessageHandler消息處理程序(基類)
publicabstractclassHttpMessageHandler : IDisposable { protectedHttpMessageHandler(); publicvoidDispose(); protectedvirtualvoidDispose(booldisposing); protectedinternalabstractTaskSendAsync(HttpRequestMessagerequest, CancellationTokencancellationToken); }
上面的代碼中定義的是消息處理程序基類,在管道中的每一個(gè)消息處理部分都是繼承自它。
并且定義了一個(gè)會(huì)執(zhí)行異步操作的SendAsync()方法,這個(gè)方法也是串聯(lián)管道中各個(gè)消息處理程序的一個(gè)入口,但是并不是靠它來(lái)串聯(lián)。
DelegatingHandler消息處理程序(基類)
publicabstractclassDelegatingHandler : HttpMessageHandler { protectedDelegatingHandler(); protectedDelegatingHandler(HttpMessageHandlerinnerHandler); publicHttpMessageHandlerInnerHandler { get; set; } protectedoverridevoidDispose(booldisposing); protectedinternaloverrideTaskSendAsync(HttpRequestMessagerequest, CancellationTokencancellationToken); }
這里的DelegatingHandler繼承自HttpMessageHandler類型,而且DelegatingHandler也是抽象類型,DelegatingHandler類型并不是就是簡(jiǎn)單的繼承,而是對(duì)基類進(jìn)行了擴(kuò)展,使之變成一個(gè)帶指向箭頭(對(duì)象引用)的對(duì)象類型也就是InnerHandler屬性,InnerHandler屬性的值就是在當(dāng)前這個(gè)消息處理程序的下一個(gè)消息處理程序,DelegatingHandler類型對(duì)基類的擴(kuò)展,HttpMessageHandler類型我感覺(jué)它的存在就是一個(gè)規(guī)范,從管道中的第一個(gè)處理程序開(kāi)始一直到最后一個(gè),除了最后一個(gè)消息處理程序,其他的都是DelegatingHandler類型的子類(當(dāng)然也是HttpMessageHandler的子類),最后一個(gè)消息處理程序是直接繼承自HttpMessageHandler類型,因?yàn)樗亲詈笠粋€(gè)處理程序了不必要有指向下一個(gè)處理程序的屬性,這種對(duì)職責(zé)的劃分真的很優(yōu)美,說(shuō)不出好在哪就是覺(jué)得漂亮。
HttpServer消息處理程序(實(shí)現(xiàn)類-管道頭)
publicclassHttpServer : DelegatingHandler { publicHttpServer(); publicHttpServer(HttpConfigurationconfiguration); publicHttpServer(HttpMessageHandlerdispatcher); publicHttpServer(HttpConfigurationconfiguration, HttpMessageHandlerdispatcher); publicHttpConfigurationConfiguration { get; } publicHttpMessageHandlerDispatcher { get; } protectedoverridevoidDispose(booldisposing); protectedvirtualvoidInitialize(); protectedoverrideTaskSendAsync(HttpRequestMessagerequest, CancellationTokencancellationToken); }
HttpServer類型繼承自DelegatingHandler類型,是作為管道中第一個(gè)消息處理的,要說(shuō)明的是重載的這些構(gòu)造函數(shù),如果只是采用默認(rèn)的構(gòu)造函數(shù)的話,HttpConfiguration類型的參數(shù)默認(rèn)的就是實(shí)例化HttpConfiguration類型,而HttpMEssageHandler類型的參數(shù)默認(rèn)的是實(shí)例化HttpRoutingDispatcher類型的消息處理器,并且是賦值到Dispatcher屬性的,是作為管道中最后一個(gè)消息處理器的(真正的操作實(shí)際不是它,后面篇幅會(huì)有講到)。
HttpRoutingDispatcher消息處理程序(實(shí)現(xiàn)類-管道尾)
publicclassHttpRoutingDispatcher : HttpMessageHandler { //Fields privatereadonlyHttpConfiguration_configuration; privatereadonlyHttpMessageInvoker_defaultInvoker; //Methods publicHttpRoutingDispatcher(HttpConfigurationconfiguration); publicHttpRoutingDispatcher(HttpConfigurationconfiguration, HttpMessageHandlerdefaultHandler); privatestaticvoidRemoveOptionalRoutingParameters(IDictionaryrouteValueDictionary); protectedoverrideTask SendAsync(HttpRequestMessagerequest, CancellationTokencancellationToken); }
HttpRoutingDispatcher類型繼承自HttpMessageHandler類型,上面也說(shuō)到過(guò)它是作為在管道中最后一個(gè)消息處理器的,說(shuō)是可以這么說(shuō),但是真正執(zhí)行的卻不是它,而是在執(zhí)行重載的構(gòu)造函數(shù)的時(shí)候會(huì)默認(rèn)的生成HttpControllerDispatcher類型作為HttpMessageHandler類型的構(gòu)造函數(shù)參數(shù),這里就不對(duì)它進(jìn)行過(guò)多的闡述了,后面的篇幅自然會(huì)說(shuō)明的很詳細(xì)。
下面我們來(lái)看一下ASP.NET Web API管道的大概示意圖。
圖1
(藍(lán)色線條表示請(qǐng)求,紅色線條表示響應(yīng))
這樣的示意圖說(shuō)明的不是太清晰下面我們用《ASP.NET Web API 開(kāi)篇介紹示例》中的SelfHost環(huán)境下的示例來(lái)演示一下,這樣大家自然就會(huì)清楚這個(gè)流程了。
首先我們定義一個(gè)消息處理器類型命令為CustomDelegatingHandler,并且繼承自DelegatingHandler類型。示例代碼如下
代碼1-1
publicclassCustomDelegatingHandler : DelegatingHandler { protectedoverrideTaskSendAsync(HttpRequestMessagerequest, System.Threading.CancellationTokencancellationToken) { Console.WriteLine(request.RequestUri.OriginalString+"____"+request.Method.Method); Task responseMessage=base.SendAsync(request, cancellationToken); Console.WriteLine(responseMessage.Result.RequestMessage.Method.Method); returnresponseMessage; } }
隨之我們?cè)赟elfHost環(huán)境下的服務(wù)端在注冊(cè)路由之后注冊(cè)剛才我們新建的消息處理程序?qū)ο?,示例代碼如下:
代碼1-2
staticvoidMain(string[] args) { HttpSelfHostConfigurationselfHostConfiguration= newHttpSelfHostConfiguration("http://localhost/selfhost"); using (HttpSelfHostServerselfHostServer=newHttpSelfHostServer(selfHostConfiguration)) { selfHostServer.Configuration.Routes.MapHttpRoute( "DefaultApi", "api/{controller}/{id}", new { id=RouteParameter.Optional }); RegistrationMessageHandler(selfHostServer.Configuration); selfHostServer.OpenAsync(); Console.WriteLine("
在注冊(cè)完畢,并且服務(wù)器已經(jīng)啟動(dòng)開(kāi)啟請(qǐng)求監(jiān)聽(tīng),客戶端也隨之發(fā)出請(qǐng)求之后,我們?cè)賮?lái)看一下客戶端發(fā)出的請(qǐng)求以及類型,如下圖。
圖2
這個(gè)時(shí)候我們?cè)賮?lái)看一下服務(wù)端管道處理情況,如下圖。
圖3
每一個(gè)紅框圈中的部分都表示著一個(gè)請(qǐng)求和響應(yīng)的流程跟圖2中的所有請(qǐng)求是對(duì)應(yīng)的,可以從代碼1-1中就可以看出輸出的內(nèi)容。
如果說(shuō)這樣的示例并不不明顯,不能讓人很清楚明白的了解管道的執(zhí)行過(guò)程以及順序,那我們定義兩個(gè)處理程序,并且修改代碼1-1,示例代碼如下:
代碼1-3
publicclassCustomDelegatingHandler : DelegatingHandler { protectedoverrideTaskSendAsync(HttpRequestMessagerequest, System.Threading.CancellationTokencancellationToken) { Console.WriteLine(this.GetType().Name+":"+request.RequestUri.OriginalString+"____"+request.Method.Method); Task responseMessage=base.SendAsync(request, cancellationToken); Console.WriteLine(this.GetType().Name+":"+responseMessage.Result.RequestMessage.Method.Method); returnresponseMessage; } } publicclassCustomDelegatingHandler_1 : DelegatingHandler { protectedoverrideTask SendAsync(HttpRequestMessagerequest, System.Threading.CancellationTokencancellationToken) { Console.WriteLine(this.GetType().Name+":"+request.RequestUri.OriginalString+"____"+request.Method.Method); Task responseMessage=base.SendAsync(request, cancellationToken); Console.WriteLine(this.GetType().Name+":"+responseMessage.Result.RequestMessage.Method.Method); returnresponseMessage; } }
隨之我們注冊(cè)管理處理程序的地方也要新增一個(gè)消息處理程序,示例代碼如下:
代碼1-4
staticvoidRegistrationMessageHandler(HttpConfigurationhttpconfiguration) { httpconfiguration.MessageHandlers.Add(newHttpMessageHandlers.CustomDelegatingHandler()); httpconfiguration.MessageHandlers.Add(newHttpMessageHandlers.CustomDelegatingHandler_1()); }
這個(gè)時(shí)候按照?qǐng)D2之前的那段說(shuō)明操作,再看一下服務(wù)端的管道處理情況,請(qǐng)求還是那些個(gè)請(qǐng)求,看下示意圖如下:
圖4
(紅框部分的代表就是跟上面所說(shuō)的一樣,一個(gè)請(qǐng)求一個(gè)響應(yīng)管道所對(duì)應(yīng)的處理情況)
最后再看一下圖5結(jié)合圖4,這樣更好更容易理解。
圖5
網(wǎng)站欄目:ASP.NETWebAPI管道模型
文章起源:http://weahome.cn/article/pcdejo.html