配置 ASP.NET Core 請求(Request)處理管道
配置 ASP.NET Core 請求(Request)處理管道
在本節中,我們將討論使用中介軟體元件為 asp.net core 應用程式配置請求處理管道。
作為應用程式啟動的一部分,我們要在Configure()
方法中設定請求處理管道。
public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
app.Run(async (context) =>
{
await context.Response.WriteAsync("Hello World!");
});
}
}
目前我們的程式碼中有 2 箇中間件在管道中 :UseDeveloperExceptionPage()方法和Run()方法
UseDeveloperExceptionPage 中介軟體:顧名思義,如果存在異常並且環境是Development
,此中介軟體會被呼叫,顯示開發異常頁面。 我們將在後面的視訊中討論這個DeveloperExceptionPage 中介軟體和環境變數的使用。
第二個中介軟體是註冊Run()
方法到管道中,它只能處理將一個資訊傳入Response
物件。 目前,它是一個響應每個請求的中介軟體,返回 Hello world。 在這種情況下,無論您的請求路徑是什麼。 所有請求都會被這個中介軟體所處理,我們得到的返回值都是這個中介軟體呼叫Response
即使您現在建立一個為52abp.html
的檔案,並且您在請求中包含該檔案的路徑,我們的應用程式也無法返回該靜態檔案。 這是因為,目前我們的請求處理管道沒有可以提供靜態檔案的中介軟體,如html檔案,影象,CSS和JavaScript檔案
。 在後面的課程中,我們將新增所需的中介軟體以便能夠提供靜態檔案。
研究下Configure()方法中的程式碼。#
app.Run(async (context) =>
{
await context.Response.WriteAsync("Hello World!");
});
程式碼說明:
- 我們呼叫 Run() 方法新增中介軟體到請求處理管道中。
- 如果將滑鼠懸停在 Run()方法上,則可以從 智慧提示中看到
Run()
方法是作為IApplicationBuilder
介面的擴充套件方法實現的。這就是我們能夠在IApplicationBuilder
物件應用程式上呼叫此Run()
方法的原因。 - 我們傳遞給
Run()
方法的引數是一個RequestDelegate
,我們可以從智慧提示中看到它。 RequestDelegate
是一個作為HttpContext
物件的引數委託。- 通過這個
HttpContext
物件,中介軟體可以訪問傳入的 http 請求和傳出的 http 響應。 - 目前,我們使用
lambda
將請求,它通過委託內聯的方式作為匿名方法傳遞,所以很多人都說 lambda 表示式是一種特殊的委託。如果你聽不明白 lambda 表示式,委託,及內聯,你可以參考學習:- 委託(delegate)
- Lambda 簡介 ,或者等我錄製 C#的基礎視訊吧。
- 使用
Run()
擴充套件方法,我們只能將一個終端中介軟體
新增到請求管道。 終端中介軟體
是我們之前已經說到過,他會使管道短路,不會去呼叫下一個中介軟體。
研究下面的程式碼#
app.Run(async (context) =>
{
await context.Response.WriteAsync("從第一個中介軟體中列印Hello World");
});
app.Run(async (context) =>
{
await context.Response.WriteAsync("從第二個中介軟體中列印Hello World");
});
- 我們使用
Run()
方法註冊了 2 箇中間件。 - 執行此專案時,我們只看到第一個中介軟體的響應,有返回值。
- 我們沒有看到第二個中介軟體的響應。
- 這是因為,使用
Run()
方法註冊的中介軟體無法呼叫管道中的下一個中介軟體。 - 因此,我們使用
Run()
方法註冊的中介軟體是終端中介軟體
如果您希望中介軟體能夠呼叫管道中的下一個中介軟體,則使用Use()
方法註冊中介軟體,如下所示。
app.Use(async (context, next) =>
{
await context.Response.WriteAsync("從第一個中介軟體中列印Hello World");
await next();
});
app.Run(async (context) =>
{
await context.Response.WriteAsync("從第二個中介軟體中列印Hello World");
});
注意,Use()
方法有 2 個引數。第一個引數是HttpContext
上下文物件,第二個引數是Func
型別,即它是代表管道中下一個中介軟體的通用委託。
我們再看看以下程式碼#
public void Configure(IApplicationBuilder app, IHostingEnvironment env,
ILogger<Startup> logger)
{
app.Use(async (context, next) =>
{
logger.LogInformation("MW1:傳入請求");
await next();
logger.LogInformation("MW1:傳出響應");
});
app.Use(async (context, next) =>
{
logger.LogInformation("MW2: 傳入請求");
await next();
logger.LogInformation("MW2: 傳出響應");
});
app.Run(async (context) =>
{
await context.Response.WriteAsync("MW3: 處理請求並生成響應");
logger.LogInformation("MW3: 處理請求並生成響應");
});
}
ILogger < Startup >
被注入到Configure()
方法中Main()
方法呼叫的CreateDefaultBuilder()
配置日誌記錄- 您可以通過檢視在 GitHub 的原始碼驗證這一點:https://github.com/aspnet/MetaPackages/blob/release/2.2/src/Microsoft.AspNetCore/WebHost.cs
- 檢查方法
ConfigureLogging()
,* 您會發現,ILogger 配置了Console,Debug和EventSource
三種. - 我們使用
依賴注入
的方式將ILogger
記錄到系統中。 - 如果使用.NET Core CLI 執行專案,則可以在“控制檯”視窗中檢視記錄的資訊
- 如果直接從
Visual Studio
執行專案,則可以在輸出視窗中
檢視記錄的資訊。從輸出視窗的下拉列表中選擇 ASP.NET Core Web Server。 - 您將看到,資訊按以下順序記錄
- MW1:傳入請求
- MW2:傳入請求
- MW3:處理請求並生成響應
- MW2:傳出響應
- MW1:傳出響應
現在將上面的輸出與微軟的官方文件中的下圖集合起來,是不是就清晰明瞭啊。吐槽下,微軟的文件有粗糙。
-
請記住,asp.net Core 中的中介軟體可以訪問傳入請求和傳出響應
-
請求先到達
Middleware1
,它記錄**(MW1:傳入請求)**,因此我們首先看到此訊息。 -
然後
Middleware1
呼叫next()
。next()
會呼叫管道中的Middleware2
。 -
Middleware2
記錄**(MW2:傳入請求)**。 -
然後
Middleware2
會呼叫next()
再呼叫Middleware3
. -
Middleware3
處理請求並生成響應。因此,我們看到的下一條訊息是(MW3:處理請求並生成響應)
-
此時管道開始逆轉。
-
此時控制權將,交回到
Middleware2
,並將Middleware3
生成的響應傳遞給它。Middleware2
記錄**(MW2:傳出響應)**,這是我們接下來看到的。 -
最後,
Middleware2
將控制權交給Midleware1
。 -
Middleware1
記錄 (MW1: 傳出響應), 這是我們最後看到的。
請求處理管道的中 3 個非常重要的知識點:#
- 所有的
請求
都會在每個中介軟體元件呼叫next()方法
之前觸發。請求
按照圖中箭頭的所示方向,依次穿過所有管道。 - 當中間件處理請求併產生響應時,請求處理流程在管道中開始反向傳遞。
- 所有的
響應
都會在每個中介軟體元件呼叫next()方法
之前觸發。響應
按照圖中箭頭的所示方向,依次穿過所有管道。
小結
Response 為抽象類
亂碼問題
context.Response.ContentType = "text/plain; charset=utf-8";