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方法,並產生響應。最后響應再從中間件管道原路返回。

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM