本文通過一張GIF動(dòng)圖來繼續(xù)聊一下ASP.NET Core的請(qǐng)求處理管道，從管道的配置、構(gòu)建以及請(qǐng)求處理流程等方面做一下詳細(xì)的研究。（ASP.NET Core系列目錄）

一、概述

　　上文說到，請(qǐng)求是經(jīng)過 Server監(jiān)聽=>處理成httpContext=>Application處理生成Response。?這個(gè)Application的類型RequestDelegate本質(zhì)是?public?delegate?Task RequestDelegate (HttpContext context);?，即接收HttpContext并返回Task， 它是由一個(gè)個(gè)中間件?Func<RequestDelegate, RequestDelegate> middleware?嵌套在一起構(gòu)成的。它的構(gòu)建是由ApplicationBuilder完成的，先來看一下這個(gè)ApplicationBuilder：

public class ApplicationBuilder : IApplicationBuilder

{

? ? private readonly IList<Func<RequestDelegate, RequestDelegate>> _components = new List<Func<RequestDelegate, RequestDelegate>>();

? ? public IApplicationBuilder Use(Func<RequestDelegate, RequestDelegate> middleware)

? ? {

? ? ? ? _components.Add(middleware);

? ? ? ? return this;

? ? }

? ? public RequestDelegate Build()

? ? {

? ? ? ? RequestDelegate app = context =>

? ? ? ? {

? ? ? ? ? ? context.Response.StatusCode = 404;

? ? ? ? ? ? return Task.CompletedTask;

? ? ? ? };?

? ? ? ? foreach (var component in _components.Reverse())20? ? ? ? ?{

? ? ? ? ? ? app = component(app);

? ? ? ? }

? ? ? ? return app;

? ? }

}

　ApplicationBuilder有個(gè)集合?IList<Func<RequestDelegate, RequestDelegate>> _components?和一個(gè)用于向這個(gè)集合中添加內(nèi)容的??Use(Func<RequestDelegate, RequestDelegate> middleware)?方法，通過它們的類型可以看出來它們是用來添加和存儲(chǔ)中間件的。現(xiàn)在說一下大概的流程：

調(diào)用startupFilters和_startup的Configure方法，調(diào)用其中定義的多個(gè)UseXXX（進(jìn)一步調(diào)用ApplicationBuilder的Use方法）將一個(gè)個(gè)中間件middleware按照順序?qū)懭肷衔牡募?span style="color:rgb(153,51,102);">_components（記住這個(gè)_components）。

定義了一個(gè)?context.Response.StatusCode =?404?的RequestDelegate。

將集合_components顛倒一下, 然后遍歷其中的middleware，一個(gè)個(gè)的與新創(chuàng)建的404?RequestDelegate 連接在一起，組成一個(gè)新的RequestDelegate（即Application）返回。

　　這個(gè)最終返回的RequestDelegate類型的Application就是對(duì)HttpContext處理的管道了，這個(gè)管道是多個(gè)中間件按照一定順序連接在一起組成的，startupFilters先不說，以我們非常熟悉的Startup為例，它的Configure方法默認(rèn)情況下已經(jīng)依次進(jìn)行了UseBrowserLink、UseDeveloperExceptionPage、UseStaticFiles、UseMvc了等方法，請(qǐng)求進(jìn)入管道后，請(qǐng)求也會(huì)按照這個(gè)順序來經(jīng)過各個(gè)中間件處理，首先進(jìn)入U(xiǎn)seBrowserLink，然后UseBrowserLink會(huì)調(diào)用下一個(gè)中間件UseDeveloperExceptionPage，依次類推到達(dá)UseMVC后被處理生成Response開始逆向返回再依次反向經(jīng)過這幾個(gè)中間件，正常情況下，請(qǐng)求到達(dá)MVC中間件后被處理生成Response開始逆向返回，而不會(huì)到達(dá)最終的404，這個(gè)404是為了防止其他層未配置或未能處理的時(shí)候的一個(gè)保險(xiǎn)操作。　　

　　胡扯兩句：這個(gè)管道就像一座塔，話說唐僧路過金光寺去掃金光塔，從前門進(jìn)入第一層開始掃，然后從前門的樓梯進(jìn)入第二層、第三層、第四層，然后從第四層的后門掃下來直至后門出去，卻不想妖怪沒處理好， 被唐僧掃到了第五層（頂層）去，發(fā)現(xiàn)佛寶被奔波兒灞和霸波爾奔偷走了，大喊：悟空悟空，佛寶被妖怪偷走啦！（404...）

　　下面就以這4個(gè)為例通過一個(gè)動(dòng)圖形象的描述一下整個(gè)過程：

　　一個(gè)“中規(guī)中矩”的管道就是這樣構(gòu)建并運(yùn)行的，通過上圖可以看到各個(gè)中間件在Startup文件中的配置順序與最終構(gòu)成的管道中的順序的關(guān)系，下面我們自己創(chuàng)建幾個(gè)中間件體驗(yàn)一下，然后再看一下不“中規(guī)中矩”的長了杈子的管道。

二、自定義中間件

　　先仿照系統(tǒng)現(xiàn)有的寫一個(gè)

public class FloorOneMiddleware

? ? {

? ? ? ? private readonly RequestDelegate _next;

? ? ? ? public FloorOneMiddleware(RequestDelegate next)

? ? ? ? {

? ? ? ? ? ? _next = next;

? ? ? ? }

? ? ? ? public async Task InvokeAsync(HttpContext context)

? ? ? ? {

? ? ? ? ? ? Console.WriteLine("FloorOneMiddleware In");

? ? ? ? ? ? //Do Something

? ? ? ? ? ? //To FloorTwoMiddleware

? ? ? ? ? ? await _next(context);

? ? ? ? ? ? //Do Something

? ? ? ? ? ? Console.WriteLine("FloorOneMiddleware Out");

? ? ? ? }

? ? }

這是塔的第一層，進(jìn)入第一層后的?//Do Something?表示在第一層需要做的工作， 然后通過?_next(context)?進(jìn)入第二層，再下面的?//Do Something?是從第二層出來后的操作。同樣第二層調(diào)用第三層也是一樣。再仿寫個(gè)UseFloorOne的擴(kuò)展方法：

public static class FloorOneMiddlewareExtensions

? ? {

? ? ? ? public static IApplicationBuilder UseFloorOne(this IApplicationBuilder builder)

? ? ? ? {

? ? ? ? ? ? Console.WriteLine("Use FloorOneMiddleware");

? ? ? ? ? ? return builder.UseMiddleware<FloorOneMiddleware>();

? ? ? ? }

? ? }

這樣在Startup的Configure方法中就也可以寫?app.UseFloorOne();?將這個(gè)中間件作為管道的一部分了。

　　通過上面的例子仿照系統(tǒng)默認(rèn)的中間件完成了一個(gè)簡單的中間件的編寫，這里也可以用簡要的寫法，直接在Startup的Configure方法中這樣寫：

app.Use(async (context,next) =>

{

? ? Console.WriteLine("FloorThreeMiddleware In");

? ? //Do Something

? ? //To FloorThreeMiddleware

? ? await next.Invoke();

? ? //Do Something

? ? Console.WriteLine("FloorThreeMiddleware Out");

});

同樣可以實(shí)現(xiàn)上一種例子的工作，但還是建議按照那樣的寫法，在Startup這里體現(xiàn)的簡潔并且可讀性好的多。

復(fù)制一下第一種和第二種的例子，形成如下代碼：

public void Configure(IApplicationBuilder app, IHostingEnvironment env)

? ? ? ? {

? ? ? ? ? ? app.UseFloorOne();

? ? ? ? ? ? app.UseFloorTwo();

? ? ? ? ? ? app.Use(async (context,next) =>

? ? ? ? ? ? {

? ? ? ? ? ? ? ? Console.WriteLine("FloorThreeMiddleware In");

? ? ? ? ? ? ? ? //Do Something

? ? ? ? ? ? ? ? //To FloorThreeMiddleware

? ? ? ? ? ? ? ? await next.Invoke();

? ? ? ? ? ? ? ? //Do Something

? ? ? ? ? ? ? ? Console.WriteLine("FloorThreeMiddleware Out");

? ? ? ? ? ? });

? ? ? ? ? ? app.Use(async (context, next) =>

? ? ? ? ? ? {

? ? ? ? ? ? ? ? Console.WriteLine("FloorFourMiddleware In");

? ? ? ? ? ? ? ? //Do Something

? ? ? ? ? ? ? ? await next.Invoke();

? ? ? ? ? ? ? ? //Do Something

? ? ? ? ? ? ? ? Console.WriteLine("FloorFourMiddleware Out");

? ? ? ? ? ? });

? ? ? ? ? ? if (env.IsDevelopment())

? ? ? ? ? ? {

? ? ? ? ? ? ? ? app.UseBrowserLink();

? ? ? ? ? ? ? ? app.UseDeveloperExceptionPage();

? ? ? ? ? ? }

? ? ? ? ? ? else

? ? ? ? ? ? {

? ? ? ? ? ? ? ? app.UseExceptionHandler("/Home/Error");

? ? ? ? ? ? }

? ? ? ? ? ? app.UseStaticFiles();

? ? ? ? ? ? app.UseMvc(routes =>

? ? ? ? ? ? {

? ? ? ? ? ? ? ? routes.MapRoute(

? ? ? ? ? ? ? ? ? ? name: "default",

? ? ? ? ? ? ? ? ? ? template: "{controller=Home}/{action=Index}/{id?}");

? ? ? ? ? ? });

? ? ? ? }

運(yùn)行一下看日志：

CoreMiddleware> Use FloorOneMiddleware

CoreMiddleware> Use FloorTwoMiddleware

CoreMiddleware> Hosting environment: Development

CoreMiddleware> Content root path: C:\Users\FlyLolo\Desktop\CoreMiddleware\CoreMiddleware

CoreMiddleware> Now listening on: http://localhost:10757

CoreMiddleware> Application started. Press Ctrl+C to shut down.

CoreMiddleware> info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]

CoreMiddleware>? ? ? ?Request starting HTTP/1.1 GET http://localhost:56440/??

CoreMiddleware> FloorOneMiddleware In

CoreMiddleware> FloorTwoMiddleware In

CoreMiddleware> FloorThreeMiddleware In

CoreMiddleware> FloorFourMiddleware In

CoreMiddleware> info: Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker[1]

CoreMiddleware>? ? ? ?Executing action method CoreMiddleware.Controllers.HomeController.Index (CoreMiddleware) with arguments ((null)) - ModelState is Valid

CoreMiddleware> info: Microsoft.AspNetCore.Mvc.ViewFeatures.Internal.ViewResultExecutor[1]

CoreMiddleware>? ? ? ?Executing ViewResult, running view at path /Views/Home/Index.cshtml.

CoreMiddleware> info: Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker[2]

CoreMiddleware>? ? ? ?Executed action CoreMiddleware.Controllers.HomeController.Index (CoreMiddleware) in 9896.6822ms

CoreMiddleware> FloorFourMiddleware Out

CoreMiddleware> FloorThreeMiddleware Out

CoreMiddleware> FloorTwoMiddleware Out

CoreMiddleware> FloorOneMiddleware Out

CoreMiddleware> info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]

CoreMiddleware>? ? ? ?Request finished in 10793.8944ms 200 text/html; charset=utf-8

可以看到，前兩行的Use?FloorOneMiddleware和Use FloorTwoMiddleware是將對(duì)應(yīng)的中間件寫入集合_components，而中間件本身并未執(zhí)行，然后10至12行是依次經(jīng)過我們自定義的例子的處理，第13-18就是在中間件MVC中的處理了，找到并調(diào)用對(duì)應(yīng)的Controller和View，然后才是19-22的逆向返回， 最終Request finished返回狀態(tài)200， 這個(gè)例子再次驗(yàn)證了請(qǐng)求在管道中的處理流程。

那么我們?cè)囈幌?04的情況， 把Configure方法中除了自定義的4個(gè)中間件外全部注釋掉，再次運(yùn)行

//上面沒變化? 省略

CoreMiddleware> FloorOneMiddleware In

CoreMiddleware> FloorTwoMiddleware In

CoreMiddleware> FloorThreeMiddleware In

CoreMiddleware> FloorFourMiddleware In

CoreMiddleware> FloorFourMiddleware Out

CoreMiddleware> FloorThreeMiddleware Out

CoreMiddleware> FloorTwoMiddleware Out

CoreMiddleware> FloorOneMiddleware Out

CoreMiddleware> info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]

CoreMiddleware>? ? ? ?Request finished in 218.7216ms 404

可以看到，MVC處理的部分沒有了，因?yàn)樵撝虚g件已被注釋，而最后一條可以看到系統(tǒng)返回了狀態(tài)404。

?那么既然MVC可以正常處理請(qǐng)求沒有進(jìn)入404， 我們?cè)趺醋隹梢赃@樣呢？是不是不調(diào)用下一個(gè)中間件就可以了？ 試著把FloorFour改一下

app.Use(async (context, next) =>

{

? ? Console.WriteLine("FloorFourMiddleware? In");

? ? //await next.Invoke();

? ? await context.Response.WriteAsync("Danger!");

? ? Console.WriteLine("FloorFourMiddleware? Out");

});

再次運(yùn)行，查看輸出和上文的沒有啥太大改變， 只是最后的404變?yōu)榱?00， 網(wǎng)頁上的“404 找不到。?！币沧兂闪宋覀円筝敵龅?#34;Danger!", 達(dá)到了我們想要的效果。

但一般情況下我們不這樣寫，ASP.NET Core 提供了Use、Run和Map三種方法來配置管道。

三、Use、Run和Map

　　Use上面已經(jīng)用過就不說了，對(duì)于上面的問題， 一般用Run來處理，Run主要用來做為管道的末尾，例如上面的可以改成這樣：

app.Run(async (context) =>{ ?
? ?await context.Response.WriteAsync("Danger!"); });

　因?yàn)楸旧硭褪亲鳛楣艿滥┪?#xff0c;也就省略了next參數(shù)，雖然用use也可以實(shí)現(xiàn)， 但還是建議用Run。

?　? Map：

　　?static?IApplicationBuilder Map(this?IApplicationBuilder app, PathString pathMatch, Action<IApplicationBuilder> configuration);?pathMatch用于匹配請(qǐng)求的path， 例如“/Home”, 必須以“/”開頭， 判斷path是否是以pathMatch開頭。

若是，則進(jìn)入?Action<IApplicationBuilder> configuration)?，?這個(gè)參數(shù)是不是長得很像startup的Configure方法？ 這就像進(jìn)入了我們配置的另一個(gè)管道，它是一個(gè)分支，如下圖

圖2

做個(gè)例子：

app.UseFloorOne();

app.Map("/Manager", builder =>

{

? ? builder.Use(async (context, next) =>

? ? {

? ? ? ? await next.Invoke();

? ? });

? ? builder.Run(async (context) =>

? ? {

? ? ? ? await context.Response.WriteAsync("Manager.");

? ? });

});

app.UseFloorTwo();

　進(jìn)入第一層后， 添加了一個(gè)Map， 作用是當(dāng)我們請(qǐng)求?localhost:56440/Manager/index?這樣的地址的時(shí)候（是不是有點(diǎn)像Area）， 會(huì)進(jìn)入這個(gè)Map創(chuàng)建的新分支， 結(jié)果也就是頁面顯示"Manager." 不會(huì)再進(jìn)入下面的FloorTwo。若不是“/Manager”開頭的， 這繼續(xù)進(jìn)入FloorTwo。雖然感覺這個(gè)Map靈活了我們的管道配置， 但這個(gè)只能匹配path開頭的方法太局限了，不著急， 我們看一下MapWhen。

　　Map When：

　　MapWhen方法就是一個(gè)靈活版的Map，它將原來的PathMatch替換為一個(gè)?Func<HttpContext,?bool> predicate?，這下就開放多了，它返回一個(gè)bool值，現(xiàn)在舉個(gè)栗子隨便改一下

app.MapWhen(context=> {return context.Request.Query.ContainsKey("XX");}, builder =>{ ? ?//...TODO...}

　　當(dāng)根據(jù)請(qǐng)求的參數(shù)是否包含“XX”的時(shí)候進(jìn)入這個(gè)分支。

　　從圖2可知，一旦進(jìn)入分支，是無法回到原分支的，?如果只是想在某種情況下進(jìn)入某些中間件，但執(zhí)行完后還可以繼續(xù)后續(xù)的中間件怎么辦呢？對(duì)比MapWhen，Use也有個(gè)UseWhen。

　　UseWhen：

　　?它和MapWhen一樣，當(dāng)滿足條件的時(shí)候進(jìn)入一個(gè)分支，在這個(gè)分支完成之后再繼續(xù)后續(xù)的中間件，當(dāng)然前提是這個(gè)分支中沒有Run等短路行為。

app.UseWhen(context=> {return context.Request.Query.ContainsKey("XX");}, builder =>{ ? ?//...TODO...}

四、IStartupFilter

　　我們只能指定一個(gè)Startup類作為啟動(dòng)類，那么還能在其他的地方定義管道么？ 文章開始的時(shí)候說到，構(gòu)建管道的時(shí)候，會(huì)調(diào)用startupFilters和_startup的Configure方法，調(diào)用其中定義的多個(gè)UseXXX方法來將中間件寫入_components。自定義一個(gè)StartupFilter，實(shí)現(xiàn)IStartupFilter的Configure方法，用法和Startup的Configure類似，不過要記得最后調(diào)用?next(app)?。

public class TestStartupFilter : IStartupFilter

{

? ? public Action<IApplicationBuilder> Configure(Action<IApplicationBuilder> next)

? ? {

? ? ? ? return app => {?

? ? ? ? ? ? app.Use(async (context, next1) =>

? ? ? ? ? ? {

? ? ? ? ? ? ? ? Console.WriteLine("filter.Use1.begin");

? ? ? ? ? ? ? ? await next1.Invoke();

? ? ? ? ? ? ? ? Console.WriteLine("filter.Use1.end");

? ? ? ? ? ? });

? ? ? ? ? ? next(app);

? ? ? ? };

? ? }

}

在復(fù)制一個(gè)，去startup的ConfigureServices注冊(cè)一下：

public void ConfigureServices(IServiceCollection services)

{

? ? services.AddMvc();

? ? services.AddSingleton<IStartupFilter,TestStartupFilter>();

? ? services.AddSingleton<IStartupFilter, TestStartupFilter2>();

}

這樣的配置就生效了，現(xiàn)在剖析一下他的生效機(jī)制?；仡櫼幌耊ebHost的BuildApplication方法：

private RequestDelegate BuildApplication()

{

?//....省略

? ? var startupFilters = _applicationServices.GetService<IEnumerable<IStartupFilter>>();

? ? Action<IApplicationBuilder> configure = _startup.Configure;

? ? foreach (var filter in startupFilters.Reverse())

? ? {

? ? ? ? configure = filter.Configure(configure);

? ? }

? ? configure(builder);

? ? return builder.Build();

仔細(xì)看這段代碼，其實(shí)這和構(gòu)建管道的流程非常相似，對(duì)比著說一下：

首先通過GetService獲取到注冊(cè)的IStartupFilter集合startupFilters（類比_components）

然后獲取Startup的Configure（類比404的RequestDelegate）

翻轉(zhuǎn)startupFilters，foreach它并且與Startup的Configure鏈接在一起。

上文強(qiáng)調(diào)要記得最后調(diào)用?next(app)，這個(gè)是不是和?next.Invoke()?類似。

　　是不是感覺和圖一的翻轉(zhuǎn)拼接過程非常類似，是不是想到了拼接先后順序的問題。對(duì)比著管道構(gòu)建后中間件的執(zhí)行順序，體會(huì)一下后，這時(shí)應(yīng)該可以想到各個(gè)IStartupFilter和Startup的Configure的執(zhí)行順序了吧。沒錯(cuò)就是按照依賴注入的順序：TestStartupFilter=>TestStartupFilter2=>Startup。

}

原文地址 https://www.cnblogs.com/FlyLolo/p/ASPNETCore2_8.html

---

.NET社區(qū)新聞，深度好文，歡迎訪問公眾號(hào)文章匯總 http://www.csharpkit.com

總結(jié)

以上是生活随笔為你收集整理的ASP.NET Core 2.0 : 图说管道，唐僧扫塔的故事的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。