ASP.NET Core 3.x 中間件流程與路由體系

中間件分類

 

ASP.NET Core 中間件的配置方法能夠分爲以上三種，對應的Helper方法分別是：Run(), Use(), Map()。

• Run()，使用Run調用中間件的時候，會直接返回一個響應，因此後續的中間件將不會被執行了。
• Use()，它會對請求作一些工做或處理，例如添加一些請求的上下文數據，有時候甚至什麼也不作，直接把請求交給下一個中間件。
• Map()，它會把請求從新路由到其它的中間件路徑上去。

實際中呢，Use()這個helper方法用的最多。

 

Run()：

 

 這是一個使用Run方法調用的中間件，Run方法會終止整個中間件管道，它應該返回某種類型的響應。

 

Use():

 

 Use看起來和Run差很少，可是多了一個next參數。next能夠用來調用請求管道中的下一個中間件。而當前的中間件也能夠本身返回響應，這就忽略掉了next調用。

在next調用以前，咱們能夠寫一些請求進來的邏輯，而在next調用以後，就至關於返回響應了，這時候也能夠寫一些邏輯。

在本例中，咱們下面還使用了Run方法註冊了另外一箇中間件。由於中間件會按照它們註冊的順序進行調用，因此在第一個Use方法裏執行next.Invoke()的時候，就會執行下面Run所調用的中間件。

 

Map()：

 

 Map方法能夠把請求路由到其它的中間件上面。

在這裏，若是請求的路徑以/jump結尾，那麼它所對應的handler方法，也就是HereIAm方法就會被調用，並返回一個響應。

而若是請求的路徑不是以/jump結尾，那麼HereIAm方法和裏面的中間件就不會被調用。

 

中間件Class

上面的例子，我都是使用的inline寫法的中間件。

而實際上，中間件一般是自成一個類。中間件的類須要相似這樣：

 

 自定義的中間件類須要由這幾部分組成：

• 接受一個RequestDelegate類型的參數next的構造函數。
• 按約定，還須要定義一個叫作Invoke的方法。該方法裏會包含主要的業務邏輯，而且它會被請求管道所執行。Invoke方法能夠忽略裏面的_next調用，並返回一個響應；也能夠調用_next.Invoke()把請求發送到管道的下一站。

 

中間件流程圖

 

 

 

 

 

Endpoint Routing 路由系統

ASP.NET Core 3.x 使用了一套叫作 Endpoint Routing 的路由系統。這套路由系統在ASP.NET Core 2.2的時候就已經露面了。

這套Endpoint Routing路由系統提供了更強大的功能和靈活性，以便能更好的處理請求。

 

早期ASP.NET Core的路由系統

咱們先回顧一下早期版本的ASP.NET Core的路由系統：

 

 

在早期的ASP.NET Core框架裏，HTTP請求進入中間件管道，在管道的結尾處，有一個Router中間件，也就是路由中間件。這個路由中間件會把HTTP請求和路由數據發送給MVC的一個組件，它叫作MVC Router Handler。

這個MVC 路由 Handler就會使用這些路由數據來決定哪一個Controller的Action方法應該來負責處理這個請求。

而後 Router中間件就會執行被選中的Action方法，並生成響應，而這個響應就會順着中間件的管道原路返回。

 

問題出在哪？

爲何早期的這套路由系統被拋棄了？它有什麼問題？

第一個問題就是，在被MVC處理以前，其它的中間件不知道最後哪一個Action方法會被選中來處理這個請求。這對像Authorization（受權），Cors這樣的中間件會形成很大的困擾，由於他們不能提早知道該請求會被送往哪裏。

第二個問題就是，這套流程會把MVC和路由的職責緊密的耦合在一塊兒，而實際MVC的本職工做應該僅僅就是生成響應。

 

Endpoint Routing 路由系統前來營救

Endpoint routing 路由系統，它把MVC的路由功能抽象剝離出來，並放置到中間件管道里，從而解決了早期ASP.NET Core路由系統的那兩個問題。

而在Endpoint Routing 路由系統裏，其實一共有兩個中間件，它們的名稱有點容易混淆，可是你只要記住他們的職責便可：

1. Endpoint Routing 中間件。它決定了在程序中註冊的哪一個Endpoint應該用來處理請求。
2. Endpoint 中間件。它是用來執行選中的Endpoint，從而讓其生成響應的。

 

因此，Endpoint Routing的流程圖大體以下：

 

 在這裏，Endpoint Routing 中間件會分析進來的請求，並把它和在程序中註冊的Endpoints進行比較。它會使用這些 Endpoints 上面的元數據來決定哪一個是處理該請求的最佳人選。而後，這個選中的Endpoint 就會被賦給請求的對象，而其它後續的中間件就能夠根據這個選中的Endpoint，來作一些本身的決策。在全部的中間件都執行完以後，這個被選中的Endpoint最終將被 Endpoint中間件所執行，而與之關聯的Action方法就會被執行。

 

Endpoint是什麼？

Endpoint是這樣的一些類，這些類包含一個請求的委託（Request Delegate）和其它的一些元數據，使用這些東西，Endpoint類能夠生成一個響應。

而在MVC的上下文中，這個請求委託就是一個包裝類，它包裝了一個方法，這個方法能夠實例化一個Controller並執行選中的Action方法。

Endpoint還包含元數據，這些元數據用來決定他們的請求委託是否應該用於當前的請求，仍是另有其它用途。

提及來可能有點迷糊，一會咱們看看源碼。

 

Startup.cs

以前咱們見過，ASP.NET Core裏面的Startup.cs裏面有兩個方法，分別是ConfigureServices()和Configure()，它們的職責就是註冊應用的一些服務和構建中間件請求管道。

而Startup.cs同時也是應用的路由以及Endpoint做爲其它步驟的一分部進行註冊的地方。

看圖：

 

 

 在ASP.NET Core應用程序啓動的時候，一個叫作ControllerActionEndpointDataSource的類做爲應用程序級別的服務被建立了。

這個類裏面有一個叫作CreateEndpoints()的方法，它會獲取全部Controller的Action方法。

而後針對每一個Action方法，它會建立一個Endpoint實例。這些Endpoint實例就是包裝了Controller和Action方法的執行的請求委託（Request Delegate）。

 

ControllerActionEndpointDataSource裏面包存儲着在應用程序裏註冊的路由模板。

而針對每一個Endpoint，它要麼與某個按約定的路由模板相關聯，要麼與某個Controller Action上的Attribute路由信息相關聯。而這些路由在稍後就會被用來將Endpoint與進來的請求進行匹配。

 

從Endpoint的角度查看請求-響應流程圖

 

App啓動那部分就不說了。

第一個HTTP請求進來的時候，Endpoint Routing中間件就會把請求映射到一個Endpoint上。它會使用之App啓動時建立好的EndpointDataSource，來遍歷查找全部可用的Endpoint，並檢查和它關聯的路由以及元數據，來找到最匹配的Endpoint。

一旦某個Endpoint實例被選中，它就會被附加在請求的對象上，這樣它就能夠被後續的中間件所使用了。

最後在管道的盡頭，當 Endpoint中間件運行的時候，它就會執行Endpoint所關聯的請求委託。這個請求委託就會觸發和實例化選中的Controller和Action方法，併產生響應。最後響應再從中間件管道原路返回。