幾乎任何服務器端處理環境都有自己的直通組件管道，用于檢查、重路由或修改傳入請求和傳出響應。經典 ASP.NET 圍繞 HTTP 模塊理念進行排列，而 ASP.NET Core 采用基于中間件組件的更現代的體系結構。最終目的是相同的 - 允許可配置的外部模塊以請求（以及稍后的響應）在服務器環境中傳遞的方式進行干預。中間件組件的主要目的是以某種方式改變和篩選數據流（在某些特定情況下，只是使請求短路，停止任何進一步的處理）。

ASP.NET Core 管道自框架 1.0 版發布以來幾乎沒有變化，但即將發布的 ASP.NET Core 3.0 邀請了一些關于當前體系結構的評論，這些評論在很大程度上被忽略了。因此，在本文中，我將重新討論 ASP.NET Core 運行時管道的整體功能，并著重介紹 HTTP 終結點的角色和可能的實現。

適用于 Web 后端的 ASP.NET Core

特別是在過去幾年，構建前端和后端完全解耦的 Web 應用程序已經變得相當普遍。因此，大多數 ASP.NET Core 項目現在都是簡單的沒有 UI 的 Web API 項目，僅為單頁面和/或移動應用程序提供 HTTP 外觀，大多數情況下，這些應用通過 Angular、React、Vue 及其移動對等項構建而成。

當你意識到這一點，將出現一個問題：在不使用任何 Razor 工具的應用程序中，綁定到 MVC 應用程序模型是否仍有意義？MVC 模型并不是免費的，事實上，在某種程度上，一旦停止使用控制器來提供操作結果，它甚至可能不是最輕量級的選項。進一步追問：如果大部分 ASP.NET Core 代碼編寫只是為了返回 JSON 有效負載，那么操作結果概念本身是否絕對必要？

帶著這些想法，讓我們回顧一下 ASP.NET Core 管道和中間件組件的內部結構，以及可以在啟動期間綁定到的內置運行時服務列表。

啟動類

在任何 ASP.NET Core 應用程序中，一個類被指定為應用程序引導程序。大多數情況下，此類采用名稱“Startup”。該類在 Web 主機配置中聲明為啟動類，Web 主機通過反射實例化并調用該類。該類可以有兩種方法 - ConfigureServices（可選）和 Configure。在第一個方法中，你將接收當前（默認）運行時服務列表，并需要添加更多服務來為實際應用程序邏輯做準備。在 Configure 方法中，為默認服務和顯式請求支持應用程序的服務進行配置。

Configure 方法接收至少一個應用程序生成器類實例。可以將此實例視為傳遞給代碼的 ASP.NET 運行時管道的工作實例，以便根據需要進行配置。一旦 Configure 方法返回，管道工作流將配置完畢，并用于執行從連接的客戶端發送的任何進一步請求。圖 1 提供了 Startup 類的 Configure 方法的實現示例。

圖 1 Startup 類中 Configure 方法的基本示例

Use 擴展方法是用于將中間件代碼添加到其他空管道工作流的主要方法。注意，添加的中間件越多，服務器需要執行更多的工作來滿足任何傳入請求。最小的是管道，最快的是客戶端至第一字節的時間 (TTFB)。

可以使用 lambdas 或臨時中間件類向管道添加中間件代碼。這完全由你來決定：lambda 更直接，但類（最好是一些擴展方法）將使整個過程更易于閱讀和維護。中間件代碼獲取請求的 HTTP 上下文和對管道中下一個中間件的引用（如果有的話）。圖 2 顯示了各種中間件組件鏈接在一起的總體視圖。

圖 2 ASP.NET Core 運行時管道

每個中間件組件都有兩次機會介入正在進行的請求的生命周期。它可以預先處理從先前注冊運行的組件鏈接收到的請求，然后它會被鏈中的下一個組件取代。當鏈中的最后一個組件有機會預先處理請求時，請求會被傳遞給終止中間件，以便進行實際處理，目的是生成具體輸出。之后，組件鏈按相反順序返回，如圖 2 所示，每個中間件都有第二次處理的機會 - 不過，這一次將是后處理操作。在圖 1 代碼中，預處理代碼與后處理代碼的分割線為：

終止中間件

在圖 2 所示的體系結構中，關鍵是終止中間件的角色，它是 Configure 方法底部的代碼，用于終止鏈并處理請求。所有演示 ASP.NET Core 應用程序都有一個終止的 lambda，如下所示：

lambda 接收 HttpContext 對象，并在應用程序上下文中執行它應執行的任何操作。

實際上，有意不生成到下一個組件的中間件組件將終止鏈，進而導致響應被發送到請求的客戶端。UseStaticFiles 中間件就是一個很好的例子，它在指定的 Web 根文件夾下提供靜態資源，并終止請求。另一個示例是 UseRewriter，它可以命令客戶端重定向到新 URL。在沒有終止中間件的情況下，請求很難在客戶端上產生一些可見輸出，盡管響應仍然通過運行中間件（例如，通過添加 HTTP 標頭或響應 cookie）以修改后的形式發送。

還有兩個專用的中間件工具也可用于短路請求：app.Map 和 app.MapWhen。前者檢查請求路徑是否匹配參數并運行自己的終止中間件，如下所示：

而后者僅在驗證了指定布爾條件后才運行自己的終止中間件。布爾條件來自接受 HttpContext 的函數計算。圖 3 中的代碼提供了一個非常精簡的小型 Web API，它僅為單個終結點提供服務，并且在沒有任何類似于控制器類項的情況下執行該操作。

圖 3 極小型 ASP.NET Core Web API

如果 URL 匹配 /country，終止中間件將從查詢字符串中讀取一個參數，并安排對存儲庫的調用，以獲得匹配國家/地區列表。然后，對列表對象以 JSON 格式直接手動序列化到輸出流。通過添加一些其他映射路由，你甚至可以擴展 Web API。再簡單不過了。

MVC 怎么樣？

在 ASP.NET Core 中，整個 MVC 機制作為黑盒運行時服務提供。只需綁定到 ConfigureServices 方法中的服務，并在 Configure 方法中配置其路由，如下面的代碼所示：

此時，如果你打算提供 HTML，歡迎填充常用的 Controllers 文件夾，甚至 Views 文件夾。注意在 ASP.NET Core 還可以使用 POCO 控制器，它是簡單的 C# 類，經修飾后可以被識別為控制器，并與 HTTP 上下文斷開連接。

MVC 機制是終止中間件的另一個很好的示例。一旦請求被 MVC 中間件捕獲，一切都在它的控制之下，管道會突然終止。

有趣的是，MVC 機制在內部運行自己的自定義管道。它不以中間件為中心，但它仍然是一個完整的運行時管道，控制請求如何路由到控制器操作方法，并最終將生成的操作結果呈現到輸出流。MVC 管道由在各個控制器方法前后運行的各種類型的操作篩選器（操作名稱選擇器、授權篩選器、異常處理程序、自定義操作結果管理器）組成。在 ASP.NET Core 中，內容協商也隱藏在運行時管道中。

從更深刻的角度來看，整個 ASP.NET MVC 機制看起來就像是被固定在最新的、經重新設計的、以中間件為中心的 ASP.NET Core 管道的上方。就像 ASP.NET Core 管道和 MVC 機制是不同類型的實體，只是以某種方式連接在一起。總體情況與 MVC 被固定在現已被摒棄的 Web 窗體運行時之上的方式沒有太大不同。實際上，在該上下文中，如果處理請求無法與物理文件匹配（很可能是 ASPX 文件），MVC 就會通過專用的 HTTP 處理程序啟動。

這有問題嗎？很可能沒有。也許問題還沒出現！

將 SignalR 置于循環中

將 SignalR 添加到 ASP.NET Core 應用程序時，需要做的就是創建一個中心類來公開終結點。有趣的是中心類可能與控制器完全不相關。不需要 MVC 來運行 SignalR，但中心類的行為類似于外部請求的前端控制器。從中心類公開的方法可以執行任何工作 - 甚至與框架的跨應用通知性質無關的工作，如圖 4 所示。

圖 4 從中心類公開方法

能看到圖片嗎？

SignalR 中心類可以被視為一個控制器類，不需要整個 MVC 機制，非常適合無 UI（或者更確切地說，是 Razor）響應。

將 gRPC 置于循環中

在 3.0 版本中，ASP.NET Core 還提供了對 gRPC 框架的本機支持。該框架設計為與 RPC 準則一起使用，是圍繞接口定義語言的一層代碼，接口定義語言完全定義終結點，并且能夠使用 HTTP/2 上的 Protobuf 二進制序列化觸發連接方之間的通信。從 ASP.NET Core 3.0 角度來看，gRPC 還是另一個可調用外觀，可以進行服務器端計算并返回值。下面介紹了如何啟用 ASP.NET Core 服務器應用程序以支持 gRPC：

另請注意全局路由的使用，以使應用程序支持沒有 MVC 機制的路由。可以將 UseRouting 視為定義 app.Map 中間件塊的一種更結構化的方法。

前面代碼的凈效果是支持從客戶端應用程序到映射服務的 RPC 樣式調用，即 Greeter-Service 類。有趣的是，GreeterService 類在概念上等同于 POCO 控制器，只不過它不需要被識別為控制器類，如下所示：

基類（GreeterBase 是一個封裝在靜態類中的抽象類）包含執行請求/響應通信所需的管道。gRPC 服務類與 ASP.Net Core 基礎結構完全集成，可以注入外部引用。

底線

特別是隨著 ASP.NET Core 3.0 的發布，將會出現另外兩種情況，在這些情況下，使用無 MVC 的控制器樣式外觀將會很有幫助。SignalR 有一個中心類，gRPC 有一個服務類，但關鍵是它們在概念上是相同的，必須在不同的場景以不同方式實現這些類。MVC 機制已或多或少被移植到 ASP.NET Core，因為它最初是為經典 ASP.NET 設計的，并圍繞控制器和操作結果維護自己的內部管道。與此同時，隨著 ASP.NET Core 越來越廣泛地被用作普通后端服務提供程序（不支持視圖），對 HTTP 終結點可能統一的 RPC 樣式外觀的需求也在增長。

原文地址：https://msdn.microsoft.com/zh-cn/magazine/mt833464

---

.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總?http://www.csharpkit.com?

總結

以上是生活随笔為你收集整理的ASP.NET Core 管道再探的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。