?2016-2026 Matools All rights reserved,
粵ICP備17059708號
中間件分類
?
ASP.NET Core 中間件的配置方法可以分為以上三種，對應的Helper方法分別是：Run(), Use(), Map()。
* Run()，使用Run調(diào)用中間件的時候，會直接返回一個響應，所以后續(xù)的中間件將不會被執(zhí)行了。
* Use()，它會對請求做一些工作或處理，例如添加一些請求的上下文數(shù)據(jù)，有時候甚至什么也不做，直接把請求交給下一個中間件。
* Map()，它會把請求重新路由到其它的中間件路徑上去。
實際中呢，Use()這個helper方法用的最多。
?
Run()：
?
?這是一個使用Run方法調(diào)用的中間件，Run方法會終止整個中間件管道，它應該返回某種類型的響應。
?
Use():
?
?Use看起來和Run差不多，但是多了一個next參數(shù)。next可以用來調(diào)用請求管道中的下一個中間件。而當前的中間件也可以自己返回響應，這就忽略掉了next調(diào)用。
在next調(diào)用之前，我們可以寫一些請求進來的邏輯，而在next調(diào)用之后，就相當于返回響應了，這時候也可以寫一些邏輯。
在本例中，我們下面還使用了Run方法注冊了另一個中間件。因為中間件會按照它們注冊的順序進行調(diào)用，所以在第一個Use方法里執(zhí)行next.Invoke()的時候，就會執(zhí)行下面Run所調(diào)用的中間件。
?
Map()：
?
?Map方法可以把請求路由到其它的中間件上面。
在這里，如果請求的路徑以/jump結(jié)尾，那么它所對應的handler方法，也就是HereIAm方法就會被調(diào)用，并返回一個響應。
而如果請求的路徑不是以/jump結(jié)尾，那么HereIAm方法和里面的中間件就不會被調(diào)用。
?
中間件Class
上面的例子，我都是使用的inline寫法的中間件。
而實際上，中間件通常是自成一個類。中間件的類需要類似這樣：
?
?自定義的中間件類需要由這幾部分組成：
* 接受一個RequestDelegate類型的參數(shù)next的構(gòu)造函數(shù)。
*
按約定，還需要定義一個叫做Invoke的方法。該方法里會包含主要的業(yè)務邏輯，并且它會被請求管道所執(zhí)行。Invoke方法可以忽略里面的_next調(diào)用，并返回一個響應；也可以調(diào)用_next.Invoke()把請求發(fā)送到管道的下一站。
?
中間件流程圖
?
?
?
?
?
Endpoint Routing 路由系統(tǒng)
ASP.NET Core 3.x 使用了一套叫做 Endpoint Routing 的路由系統(tǒng)。這套路由系統(tǒng)在ASP.NET Core
2.2的時候就已經(jīng)露面了。
這套Endpoint Routing路由系統(tǒng)提供了更強大的功能和靈活性，以便能更好的處理請求。
?
早期ASP.NET Core的路由系統(tǒng)
我們先回顧一下早期版本的ASP.NET Core的路由系統(tǒng)：
?
?
在早期的ASP.NET
Core框架里，HTTP請求進入中間件管道，在管道的結(jié)尾處，有一個Router中間件，也就是路由中間件。這個路由中間件會把HTTP請求和路由數(shù)據(jù)發(fā)送給MVC的一個組件，它叫做MVC
Router Handler。
這個MVC 路由 Handler就會使用這些路由數(shù)據(jù)來決定哪個Controller的Action方法應該來負責處理這個請求。
然后 Router中間件就會執(zhí)行被選中的Action方法，并生成響應，而這個響應就會順著中間件的管道原路返回。
?
問題出在哪？
為什么早期的這套路由系統(tǒng)被拋棄了？它有什么問題？
第一個問題就是，在被MVC處理之前，其它的中間件不知道最后哪個Action方法會被選中來處理這個請求。這對像Authorization（授權(quán)），Cors這樣的中間件會造成很大的困擾，因為他們不能提前知道該請求會被送往哪里。
第二個問題就是，這套流程會把MVC和路由的職責緊密的耦合在一起，而實際MVC的本職工作應該僅僅就是生成響應。
?
Endpoint Routing 路由系統(tǒng)前來營救
Endpoint routing 路由系統(tǒng)，它把MVC的路由功能抽象剝離出來，并放置到中間件管道里，從而解決了早期ASP.NET
Core路由系統(tǒng)的那兩個問題。
而在Endpoint Routing 路由系統(tǒng)里，其實一共有兩個中間件，它們的名稱有點容易混淆，但是你只要記住他們的職責即可：
* Endpoint Routing 中間件。它決定了在程序中注冊的哪個Endpoint應該用來處理請求。
* Endpoint 中間件。它是用來執(zhí)行選中的Endpoint，從而讓其生成響應的。
?
所以，Endpoint Routing的流程圖大致如下：
?
?在這里，Endpoint Routing 中間件會分析進來的請求，并把它和在程序中注冊的Endpoints進行比較。它會使用這些 Endpoints
上面的元數(shù)據(jù)來決定哪個是處理該請求的最佳人選。然后，這個選中的Endpoint
就會被賦給請求的對象，而其它后續(xù)的中間件就可以根據(jù)這個選中的Endpoint，來做一些自己的決策。在所有的中間件都執(zhí)行完之后，這個被選中的Endpoint最終將被
Endpoint中間件所執(zhí)行，而與之關(guān)聯(lián)的Action方法就會被執(zhí)行。
?
Endpoint是什么？
Endpoint是這樣的一些類，這些類包含一個請求的委托（Request
Delegate）和其它的一些元數(shù)據(jù)，使用這些東西，Endpoint類可以生成一個響應。
而在MVC的上下文中，這個請求委托就是一個包裝類，它包裝了一個方法，這個方法可以實例化一個Controller并執(zhí)行選中的Action方法。
Endpoint還包含元數(shù)據(jù)，這些元數(shù)據(jù)用來決定他們的請求委托是否應該用于當前的請求，還是另有其它用途。
說起來可能有點迷糊，一會我們看看源碼。
?
Startup.cs
之前我們見過，ASP.NET
Core里面的Startup.cs里面有兩個方法，分別是ConfigureServices()和Configure()，它們的職責就是注冊應用的一些服務和構(gòu)建中間件請求管道。
而Startup.cs同時也是應用的路由以及Endpoint作為其它步驟的一分部進行注冊的地方。
看圖：
?
?
?在ASP.NET
Core應用程序啟動的時候，一個叫做ControllerActionEndpointDataSource的類作為應用程序級別的服務被創(chuàng)建了。
這個類里面有一個叫做CreateEndpoints()的方法，它會獲取所有Controller的Action方法。
然后針對每個Action方法，它會創(chuàng)建一個Endpoint實例。這些Endpoint實例就是包裝了Controller和Action方法的執(zhí)行的請求委托（Request
Delegate）。
?
ControllerActionEndpointDataSource里面包存儲著在應用程序里注冊的路由模板。
而針對每個Endpoint，它要么與某個按約定的路由模板相關(guān)聯(lián)，要么與某個Controller
Action上的Attribute路由信息相關(guān)聯(lián)。而這些路由在稍后就會被用來將Endpoint與進來的請求進行匹配。
?
從Endpoint的角度查看請求-響應流程圖
?
App啟動那部分就不說了。
第一個HTTP請求進來的時候，Endpoint
Routing中間件就會把請求映射到一個Endpoint上。它會使用之App啟動時創(chuàng)建好的EndpointDataSource，來遍歷查找所有可用的Endpoint，并檢查和它關(guān)聯(lián)的路由以及元數(shù)據(jù)，來找到最匹配的Endpoint。
一旦某個Endpoint實例被選中，它就會被附加在請求的對象上，這樣它就可以被后續(xù)的中間件所使用了。
最后在管道的盡頭，當
Endpoint中間件運行的時候，它就會執(zhí)行Endpoint所關(guān)聯(lián)的請求委托。這個請求委托就會觸發(fā)和實例化選中的Controller和Action方法，并產(chǎn)生響應。最后響應再從中間件管道原路返回。
?
熱門工具 換一換