解讀ASP.NET 5 & MVC6系列教程（6）：Middleware詳解_自學過程

在第1章項目結構分析中，我們提到Startup.cs作為整個程式的進入點，等同於傳統的Global.asax檔案，即：用於初始化系統級的資訊（例如，MVC中的路由配置）。本章我們就來一一分析，在這裡如何初始化這些系統級的資訊。

新舊版本之間的Pipeline區別

ASP.NET 5和之前版本的最大區別是對HTTP Pipeline的全新重寫，在之前的版本中，請求過濾器的通常是以HttpModule為模組組件，這些組件針對HttpApplication裡定義的各個周期內的事件進行響應，從而用於實現認證、全域錯誤處理、日誌等功能。傳統的Form表單認證就是一個HTTPModule。HTTPModule不僅能夠過濾Request請求，還可以和Response響應進行互動並修改。這些HTTPModule組件都繼承於IHttpModule介面，而該介面是位於System.Web.dll中。

HttpModule代碼不僅可以在Global.asax中的各事件周期中進行添加，還可以單獨編譯成類庫並在web.config中進行註冊。

新版的ASP.NET 5拋棄了重量級的System.Web.dll，相應地引入了Middleware的概念，Middleware的官方定義如下：

Pass through components that form a pipeline between a server and application to inspect, route, or modify request and response messages for a specific purpose.
在伺服器和應用程式之間的管線Pipeline之間，針對特定的目的，穿插多個Middleware組件，從而對request請求和response響應進行檢
查、路由、或修改。

該定義和傳統的HttpModule以及HttpHandler特別像。

Middleware的註冊和配置

在ASP.NET5中，request請求管線（Pipeline）的訪問是在Startup類中進行的，該類時一個約定類，並且裡面的ConfigureServices方法、Configure方法、以及相應的參數也是事先約定的，所以不能進行改動。

Middleware中的依賴處理：ConfigureServices方法

在ASP.NET5中的各種預設的Middleware中，都使用了依賴注入的功能，所以在使用Middleware中的功能時，需要提前將依賴注入所需要的類型及映射關係都註冊到依賴注入管理系統中，即IServiceCollection集合，而ConfigureServices方法接收的就一個IServiceCollection類型的參數，該參數就是所有註冊過類型的集合，通過原生的依賴注入組件進行管理（關於ASP.NET5中的依賴注入，我們會在單獨章節中進行講解），在該方法內，我們可以向該集合中添加新的類型和類型映射關係，樣本如下：

// Add MVC services to the services container.services.AddMvc();

樣本中的代碼用於向系統添加Mvc模組相關的Service類型以支撐MVC功能，該方法是一個擴充方法，用於在集合中添加與MVC相關的多個類型。

Middleware的註冊和配置：Configure方法

Configure方法的簽名如下：

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerfactory){ // ...}

Configure方法接收了三個參數：IApplicationBuilder類型的參數用於構建整個應用程式的配置資訊，IHostingEnvironment類的env參數用於訪問系統內容變數相關的內容，ILoggerFactory類型的loggerfactory用於日誌相關的內容處理，其中IApplicationBuilder類型的參數最為重要，該參數執行個體app上有一系列的擴充方法用於將各種Middleware註冊到request請求管線（Pipeline）中。這種方式和之前ASP.NET中的HTTP管線的主要區別是：新版本中的組合模型替換了舊版本中的事件模型。這也就要求，在新版ASP.NET中，Middleware組件註冊的順序是非常重要的，因為後一個組件可能要使用到前一個組件，所以必須按照依賴的先後順序進行註冊，舉例如下，當前MVC項目的模板程式碼範例如下：

// Add static files to the request pipeline.app.UseStaticFiles();// Add cookie-based authentication to the request pipeline.app.UseIdentity();// Add MVC to the request pipeline.app.UseMvc(routes =>{ /*...*/});

樣本中的UseStaticFiles、UseIdentity、UseMvc都是IApplicationBuilder上的擴充方法，在擴充方法中，都會通過調用擴充方法app.UseMiddleware方法，最終再調用app.Use方法來註冊新的Middleware，該方法定義如下：

public interface IApplicationBuilder{ //... IApplicationBuilder Use(Func<RequestDelegate, RequestDelegate> middleware);}

通過代碼，可以看出，middleware是Func<RequestDelegate, RequestDelegate>的一個執行個體，該Func接收一個RequestDelegate的參數，並返回一個RequestDelegate類型的值。RequestDelegate的源碼如下：

public delegate Task RequestDelegate(HttpContext context);

通過源碼，我們可以看出，RequestDelegate是一個委託函數，其接收HttpContext類型的執行個體，並返回一個Task類型的非同步對象。也就是說RequestDelegate是一個可以返回自身RequestDelegate類型函數的函數，整個ASP.NET也就是利用這種方式構建了管線（Pipelien）的組成，在這裡，每個middleware都鏈式到下一個middleware上，並在整個過程中可以對HttpConext對象進行修改或維護，當然，HttpContext中就包括了我們常操作的HttpRequest和HttpResponse執行個體對象。

注意：HttpContext、HttpRequest、HttpResponse在ASP.NET 5中都是重新定義的新類型。

Middleware的定義

既然每個middleare都是Func<RequestDelegate, RequestDelegate>的一個執行個體，那是不是Middleware的定義要滿足一個規則？是繼承於一個抽象基類還是借口？通過翻查相關的代碼，我們看到，Middleware是基於約定的形式來定義的，具體約定規則如下：

建構函式的第一個參數必須是處理管線中的下一個處理函數，即RequestDelegate；必須有一個 Invoke 函數， 並接受上下文參數（即HttpContent）， 然後返回 Task；

樣本如下：

public class MiddlewareName{ RequestDelegate _next; public MiddlewareName(RequestDelegate next) {  _next = next;// 接收傳入的RequestDelegate執行個體 } public async Task Invoke(HttpContext context) {  // 處理代碼，如處理context.Request中的內容  Console.WriteLine("Middleware開始處理");  await _next(context);  Console.WriteLine("Middleware結束處理");  // 處理代碼，如處理context.Response中的內容 }}

通過該模板代碼可以看到，首先一個Middleware的建構函式要接收一個RequestDelegate的執行個體，先儲存在一個私人變數裡，然後通過調用Invoke方法（並接收HttpContent執行個體）並返回一個Task，並且在調用Invoke的方法中，要通過await _next(context);語句，鏈式到下一個Middleware上，我們的處理代碼主要就是在鏈式語句的前後執行相關的代碼。

舉個例子，如果我們要想記錄頁面的執行時間，首先，我們先定義一個TimeRecorderMiddleware，代碼如下：

public class TimeRecorderMiddleware{ RequestDelegate _next; public TimeRecorderMiddleware(RequestDelegate next) {  _next = next; } public async Task Invoke(HttpContext context) {  var sw = new Stopwatch();  sw.Start();  await _next(context);  var newDiv = @"<div id=""process"">頁面處理時間：{0} 毫秒</div></body>";  var text = string.Format(newDiv, sw.ElapsedMilliseconds);  await context.Response.WriteAsync(text); }}

Middleware的註冊有很多種方式，如下是執行個體型註冊代碼：

app.Use(next => new TimeRecorderMiddleware(next).Invoke);

或者，你也可以使用UseMiddleware擴充方法進行註冊，樣本如下：

app.UseMiddleware<TimeRecorderMiddleware>();//app.UseMiddleware(typeof(TimeRecorderMiddleware)); 兩種方式都可以

當然，你也可以定義一個自己的擴充方法用於註冊該Middleware，代碼如下：

public static IApplicationBuilder UseTimeRecorderMiddleware(this IApplicationBuilder app){ return app.UseMiddleware<TimeRecorderMiddleware>();}

最後在Startup類的Configure方法內進行註冊，代碼如下：

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerfactory){ app.UseTimeRecorderMiddleware(); // 要放在前面，以便進行統計，如果放在Mvc後面的話，就統計不了時間了。 // 等等}

編譯，重啟，並訪問頁面，在頁面的底部即可看到頁面的已耗用時間提示內容。

常用Middleware功能的使用

app.UseErrorPage()
在IHostingEnvironment.EnvironmentName為Development的情況下，才顯示錯誤資訊，並且錯誤資訊的顯示種類，可以通過額外的ErrorPageOptions參數來設定，可以設定全部顯示，也可以設定只顯示Cookies、Environment、ExceptionDetails、Headers、Query、SourceCode SourceCodeLineCount中的一種或多種。

app.UseErrorHandler("/Home/Error")
捕獲所有的程式異常錯誤，並將請求跳轉至指定的頁面，以達到友好提示的目的。

app.UseStaticFiles()
開啟靜態檔案也能走該Pipeline管線處理流程的功能。

app.UseIdentity()
開啟以cookie為基礎的ASP.NET identity認證功能，以支援Pipeline請求處理。

直接使用委託定義Middleware的功能

由於Middleware是Func<RequestDelegate, RequestDelegate>委託類型的執行個體，所以我們也可以不必定義一個單獨的類，在Startup類裡，使用委託調用的方式就可以了，樣本如下：

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerfactory){ app.Use(new Func<RequestDelegate, RequestDelegate>(next => content => Invoke(next, content))); // 其它}// 注意Invoke方法的參數private async Task Invoke(RequestDelegate next, HttpContext content){ Console.WriteLine("初始化組件開始"); await next.Invoke(content); Console.WriteLine("管道下步執行完畢");}

做個簡便的Middleware基類

雖然有約定方法，但有時候我們在開發的時候往往會犯迷糊，想不起來到底是什麼樣的約定，所以，在這裡我們可以定義一個抽象基類，然後以後所有的Middleware在定義的時候都繼承該抽象類別並重載Invoke方法即可，從而可以避免約定忘記的問題。代碼如下：

/// <summary>/// 抽象基類/// </summary>public abstract class AbstractMiddleware{ protected RequestDelegate Next { get; set; } protected AbstractMiddleware(RequestDelegate next) {  this.Next = next; } public abstract Task Invoke(HttpContext context);}/// <summary>/// 樣本Middleware/// </summary>public class DemoMiddleware : AbstractMiddleware{ public DemoMiddleware(RequestDelegate next) : base(next) { } public async override Task Invoke(HttpContext context) {  Console.WriteLine("DemoMiddleware Start.");  await Next.Invoke(context);  Console.WriteLine("DemoMiddleware End."); }}

使用方法和上面的一樣。

終止鏈式調用或阻止所有的Middleware

在有些情況下，當然根據某些條件判斷以後，可能不在需要繼續往下執行下去了，而是想知己誒返回結果，那麼你可以在你的Middleware裡忽略對await next.Invoke(content);的調用，直接使用·Response.WriteAsync·方法輸出內容。

另外，在有些情況下，你可能需要實作類別似之前版本中的handler的功能，即不經常任何Pipeline直接對Response進行響應，新版ASP.NET裡提供了一個run方法用於實現該功能，只需要在Configure方法裡調用如下代碼即可實作類別似的內容輸出。

app.Run(async context =>{ context.Response.ContentType = "text/html"; await context.Response.WriteAsync("Hello World!");});

關於ASP.NET 5 Runtime的內容，請訪問：https://msdn.microsoft.com/en-us/magazine/dn913182.aspx

遺留問題

在Mvc項目中，所有的依賴注入類型都是通過IServiceProvider執行個體來擷取的，目前可以通過以下形式擷取該執行個體：

var services = Context.RequestServices; // Controller中var services = app.ApplicationServices; // Startup中

擷取了該執行個體以後，即可通過如下方法來擷取某個類型的對象：

var controller = (AccountController)services.GetService(typeof(AccountController));// 要判斷擷取到的對象是否為null

如果你引用了Microsoft.Framework.DependencyInjection命名空間的話，還可以使用如下三種擴充方法：

var controller2 = (AccountController)services.GetService<AccountController>(); // 要判斷擷取到的對象是否為null//如下兩種方式，如果擷取到的AccountController執行個體為null的話，就會欄位拋異常，而不是返回nullvar controller3 = (AccountController)services.GetRequiredService(typeof(AccountController));var controller4 = (AccountController)services.GetRequiredService<AccountController>();

那麼問題來了？如何不在Startup和Controller裡就可以擷取到HttpContext和IApplicationBuilder執行個體以便使用這些依賴注入服務？

如何擷取IApplicationBuilder執行個體？
答案：在Startup裡將IApplicationBuilder執行個體儲存在一個單例中的變數上，後期全站就可以使用了。

如何擷取HttpContext執行個體？
答案：參考依賴注入章節的普通類的依賴注入

引用：http://www.mikesdotnetting.com/article/269/asp-net-5-middleware-or-where-has-my-httpmodule-gone