跟我一起學.NetCore之中間件(Middleware)應用和自定義

前言

Asp.NetCore中的請求管道是通過一系列的中間件組成的，使得請求會根據需求進行對應的過濾和加工處理。在平時開發中會時常引用別人定義好的中間件，只需簡單進行app.Usexxx就能完成中間件的注冊，但是對於一些定制化需求還得自己進行處理和封裝，以下說說中間件的注冊應用和自定義中間件；

正文

在上一小節中有簡單提到，當注冊第三方封裝的中間件時，其實本質還是調用了IApplicationBuilder的Use方法；而在開發過程中，會使用以下三種方式進行中間件的注冊：

• Use：通過Use的方式注冊中間件，可以控制是否將請求傳遞到下一個中間件；
• Run：通過Run的方式注冊中間件，一般用於斷路或請求管道末尾，即不會將請求傳遞下去；
• Map/MapWhen：請求管道中增加分支，條件滿足之后就由分支管道進行處理，而不會切換回主管道；Map用於請求路徑匹配，而MapWhen可以有更多的條件進行過濾；
• UseMiddleWare : 一般用於注冊自定義封裝的中間件，內部其實是使用Use的方式進行中間件注冊；

相信都知道我的套路了，光說不練假把式，來一個Asp.NetCore API項目進行以上幾種中間件注冊方式演示：

圖中代碼部分將原先默認注冊的中間件刪除了，用Use和Run的方式分別注冊了兩個中間件(這里只是簡單的顯示文字，里面可以根據需求添加相關邏輯)，其中用Use注冊的方式在上一節中已經提及到，直接將中間件添加鏈表中，這里就不再贅述了；

對於使用Run方式注冊中間，小伙伴們肯定不甘心止於此吧，所以這里直接看Run是如何實現：

namespace Microsoft.AspNetCore.Builder
{
    public static class RunExtensions
    {
        // 也是一個擴展方法，但參數就是一個委托
        public static void Run(this IApplicationBuilder app, RequestDelegate handler)
        {
            // 參數校驗，如果null就拋出異常
            if (app == null)
            {
                throw new ArgumentNullException(nameof(app));
            }
            // 傳入的委托校驗，如果null也是拋出異常
            if (handler == null)
            {
                throw new ArgumentNullException(nameof(handler));
            }
            // 這里其實只有一個 RequestDelegate執行邏輯，並沒有傳遞功能
            // 本質也是使用方法Use
            app.Use(_ => handler);
        }
    }
}

通過代碼可知，用Run方式只是將處理邏輯RequestDelegate傳入，並沒有傳遞的邏輯，所以Run注冊的中間件就會形成斷路，導致后面的中間件不能再執行了；

使用Map和MapWhen注冊的方式，其實是給管道開一個分支，就像高速公路一樣，有匝道，到了對應出口就進匝道了，就不能倒車回來了(倒回來扣你12分);同樣，請求管道也是，當條件滿足時，請求就走Map對應的分支管道，就不能重新返回主管道了；

代碼走一波，在注冊中間件的地方增加Map的使用：

Configure全部代碼如下：

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    // 使用Use注冊中間 
    app.Use(async (context, next) => {
        await context.Response.WriteAsync("Hello Use1\r\n");
        // 將請求傳遞到下一個中間件
        await next();
​
        await context.Response.WriteAsync("Hello Use1 Response\r\n");
    });
​
    // 使用Use注冊中間   參數類型不一樣
    app.Use(requestDelegate =>
    {
        return async (context) =>
        {
            await context.Response.WriteAsync("Hello Use2\r\n");
            // 將請求傳遞到下一個中間件
            await requestDelegate(context);
​
            await context.Response.WriteAsync("Hello Use2 Response\r\n");
        };
    });
    // 分支管道，只有匹配到路徑才走分支管道
    app.Map("/Hello", builder =>
    {
        builder.Use(async (context, next) =>
        {
            await context.Response.WriteAsync("Hello MapUse\r\n");
            // 將請求傳遞到分支管道的下一個中間件
            await next();
​
            await context.Response.WriteAsync("Hello MapUse Response\r\n");
        });
        // 注冊分支管道中間件
        builder.Run(async context => {
            await context.Response.WriteAsync("Hello MapRun1~~~\r\n");
        });
        // 注冊分支管道中間件
        builder.Run(async context => {
            await context.Response.WriteAsync("Hello MapRun2~~~\r\n");
        });
    });
​
     // 使用Run 
     app.Run(async context => {
         await context.Response.WriteAsync("Hello Run~~~\r\n");
     });
​
     //使用Run注冊
     app.Run(async context => {
         await context.Response.WriteAsync("Hello Code綜藝圈~~~\r\n");
     });
}

執行看效果：

Map方式注冊的分支管道只有路徑匹配了才走，否則都會走主管道；

仔細的小伙伴肯定會說，那是在分支管道上用了Run注冊中間件了，形成了斷路，所以導致不能執行主管道剩下的中間件，好，那我們稍微改改代碼：

這樣運行訪問分支管道時會報錯，因為分支管道中沒有下一個中間件了，還調用下一個中間件，那肯定有問題；

改了改，如下運行：

進入匝道還想倒回來，12分不要了嗎，哈哈哈；

MapWhen注冊的分支管道邏輯和Map差不多類似，只是匹配的條件更加靈活而已，可以根據自己需求進行調節匹配，如下：

看到這，小伙伴應該都知道，接下來肯定不會放過Map/MapWhen的實現：

• Map

  public static IApplicationBuilder Map(this IApplicationBuilder app, PathString pathMatch, Action<IApplicationBuilder> configuration)
  {
      // 進行參數校驗 IApplicationBuilder對象不能為空
      if (app == null)
      {
          throw new ArgumentNullException(nameof(app));
      }
      // 進行參數校驗 傳進的委托對象不能為空
      if (configuration == null)
      {
          throw new ArgumentNullException(nameof(configuration));
      }
      // 匹配的路徑末尾不能有"/",否則就拋異常
      if (pathMatch.HasValue && pathMatch.Value.EndsWith("/", StringComparison.Ordinal))
      {
          throw new ArgumentException("The path must not end with a '/'", nameof(pathMatch));
      }
  ​
      // 克隆一個IApplicationBuilder，共用之前的屬性，這里其實創建了分支管道
      var branchBuilder = app.New();
      // 將創建出來的branchBuilder進行相關配置
      configuration(branchBuilder);
      // 構造出分支管道
      var branch = branchBuilder.Build();
      // 將構造出來的管道和匹配路徑進行封裝
      var options = new MapOptions
      {
          Branch = branch,
          PathMatch = pathMatch,
      };
      // 注冊中間件
      return app.Use(next => new MapMiddleware(next, options).Invoke);
  }
  ​
  // MapMiddleware 的Invoke方法，及如何進入分支管道處理的
  public async Task Invoke(HttpContext context)
  {
      // 參數判斷
      if (context == null)
      {
          throw new ArgumentNullException(nameof(context));
      }
  ​
      PathString matchedPath;
      PathString remainingPath;
  ​
      // 判斷是否匹配路徑，如果匹配上就進入分支
      if (context.Request.Path.StartsWithSegments(_options.PathMatch, out matchedPath, out remainingPath))
      {
          // 更新請求地址
          var path = context.Request.Path;
          var pathBase = context.Request.PathBase;
          context.Request.PathBase = pathBase.Add(matchedPath);
          context.Request.Path = remainingPath;
  ​
          try
          {
              // 進入分支管道
              await _options.Branch(context);
          }
          finally
          {
              // 恢復原先請求地址，回到主管道之后，並沒有進行主管道也下一個中間件的傳遞，所以主管道后續不在執行
              context.Request.PathBase = pathBase;
              context.Request.Path = path;
          }
      }
      else
      {
          // 匹配不到路徑就繼續主管道執行
          await _next(context);
      }
  }
  

• MapWhen：其實和Map差不多，只是傳入的匹配規則不一樣，比較靈活：

  public static IApplicationBuilder MapWhen(this IApplicationBuilder app, Predicate predicate, Action<IApplicationBuilder> configuration)
  {
      if (app == null)
      {
          throw new ArgumentNullException(nameof(app));
      }
  ​
      if (predicate == null)
      {
          throw new ArgumentNullException(nameof(predicate));
      }
  ​
      if (configuration == null)
      {
          throw new ArgumentNullException(nameof(configuration));
      }
  ​
      // 構建分支管道，和Map一致
      var branchBuilder = app.New();
      configuration(branchBuilder);
      var branch = branchBuilder.Build();
  ​
      // 封裝匹配規則
      var options = new MapWhenOptions
      {
          Predicate = predicate,
          Branch = branch,
      };
      // 注冊中間件
      return app.Use(next => new MapWhenMiddleware(next, options).Invoke);
  }
  // MapWhenMiddleware 的Invoke方法
  public async Task Invoke(HttpContext context)
  {
      // 參數校驗
      if (context == null)
      {
          throw new ArgumentNullException(nameof(context));
      }
      // 判斷是否匹配規則，如果匹配就進入分支管道
      if (_options.Predicate(context))
      {
          await _options.Branch(context);
      }
      else
      {
          // 沒有匹配就繼續執行主管道
          await _next(context);
      }
  }
  

現在是不是清晰明了多了，不懵了吧；還沒完呢，繼續往下；

上面注冊中間件的方式是不是有點不那么好看，當中間件多了時候，可讀性很是頭疼，維護性也得花點功夫，所以微軟肯定想到這了，提供了類的方式進行中間件的封裝(但是要按照約定來)，從而可以像使用第三方中間件那樣簡單，如下：

使用及運行：

是不是自定義也沒想象中那么難，其中注冊封裝的中間件時，在擴展方法中使用了app.UseMiddleware ()進行注冊，這個上一節中提到過，就是那段在上一節中有點嫌早的代碼，這里就拷過來了(偷個懶)：

// 看着調用的方法
public static IApplicationBuilder UseMiddleware<TMiddleware>(this IApplicationBuilder app, params object[] args)
{
    // 內部調用了以下方法
    return app.UseMiddleware(typeof(TMiddleware), args);
}
// 其實這里是對自定義中間件的注冊，這里可以不用太深入了解
public static IApplicationBuilder UseMiddleware(this IApplicationBuilder app, Type middleware, params object[] args)
{
    if (typeof(IMiddleware).GetTypeInfo().IsAssignableFrom(middleware.GetTypeInfo()))
    {
        // IMiddleware doesn't support passing args directly since it's
        // activated from the container
        if (args.Length > 0)
        {
            throw new NotSupportedException(Resources.FormatException_UseMiddlewareExplicitArgumentsNotSupported(typeof(IMiddleware)));
        }
​
        return UseMiddlewareInterface(app, middleware);
    }
    // 取得容器
    var applicationServices = app.ApplicationServices;
    // 反編譯進行包裝成注冊中間件的樣子(Func<ReuqestDelegate,RequestDelegate>)，但可以看到本質使用IApplicationBuilder中Use方法
    return app.Use(next =>
    {
        // 獲取指定類型中的方法列表
        var methods = middleware.GetMethods(BindingFlags.Instance | BindingFlags.Public);
        // 找出名字是Invoke或是InvokeAsync的方法
        var invokeMethods = methods.Where(m =>
            string.Equals(m.Name, InvokeMethodName, StringComparison.Ordinal)
            || string.Equals(m.Name, InvokeAsyncMethodName, StringComparison.Ordinal)
            ).ToArray();
        // 如果有多個方法 ，就拋出異常，這里保證方法的唯一
        if (invokeMethods.Length > 1)
        {
            throw new InvalidOperationException(Resources.FormatException_UseMiddleMutlipleInvokes(InvokeMethodName, InvokeAsyncMethodName));
        }
        // 如果沒有找到，也就拋出異常
        if (invokeMethods.Length == 0)
        {
            throw new InvalidOperationException(Resources.FormatException_UseMiddlewareNoInvokeMethod(InvokeMethodName, InvokeAsyncMethodName, middleware));
        }
        // 取得唯一的方法Invoke或是InvokeAsync方法
        var methodInfo = invokeMethods[0];
        // 判斷類型是否返回Task,如果不是就拋出異常，要求返回Task的目的是為了后續包裝RequestDelegate
        if (!typeof(Task).IsAssignableFrom(methodInfo.ReturnType))
        {
            throw new InvalidOperationException(Resources.FormatException_UseMiddlewareNonTaskReturnType(InvokeMethodName, InvokeAsyncMethodName, nameof(Task)));
        }
        // 判斷方法的參數，參數的第一個參數必須是HttpContext類型
        var parameters = methodInfo.GetParameters();
        if (parameters.Length == 0 || parameters[0].ParameterType != typeof(HttpContext))
        {
            throw new InvalidOperationException(Resources.FormatException_UseMiddlewareNoParameters(InvokeMethodName, InvokeAsyncMethodName, nameof(HttpContext)));
        }
​
        // 開始構造RequestDelegate對象
        var ctorArgs = new object[args.Length + 1];
        ctorArgs[0] = next;
        Array.Copy(args, 0, ctorArgs, 1, args.Length);
        // 這里找到參數匹配最多的構造函數進行實例創建
        var instance = ActivatorUtilities.CreateInstance(app.ApplicationServices, middleware, ctorArgs);
        // 如果參數只有一個HttpContext 就包裝成一個RequestDelegate返回
        if (parameters.Length == 1)
        {
            return (RequestDelegate)methodInfo.CreateDelegate(typeof(RequestDelegate), instance);
        }
        // 如果參數有多個的情況就單獨處理，這里不詳細進去了
        var factory = Compile<object>(methodInfo, parameters);
​
        return context =>
        {
            var serviceProvider = context.RequestServices ?? applicationServices;
            if (serviceProvider == null)
            {
                throw new InvalidOperationException(Resources.FormatException_UseMiddlewareIServiceProviderNotAvailable(nameof(IServiceProvider)));
            }
​
            return factory(instance, context, serviceProvider);
        };
    });
}

可以看出，框架將我們封裝的中間件類進行了反射獲取對應的方法和屬性，然后封裝成中間件(Func<RequestDelegate,RequestDelegate>)的樣子，從而是得編碼更加方便，中間件更容易分類管理了；通過以上代碼注釋也能看出在封裝中間件的時候對應的約定，哈哈哈，是不是得重新看一遍代碼(如果這樣，目標達到了)；對了，框架提供了IMiddleware了接口，實現中間件的時候可以實現，但是約定還是一個不能少；

總結

我去，不能熬了，再熬明天起不來跑步了；這篇內容有點多，之所以沒分開，感覺關聯性比較強，一口氣看下來比較合適；下一節說說文件相關的點；

---------------------------------------------------

CSDN：Code綜藝圈

知乎：Code綜藝圈

掘金：Code綜藝圈

博客園：Code綜藝圈

bilibili：Code綜藝圈

---------------------------------------------------

一個被程序搞丑的帥小伙，關注"Code綜藝圈"，識別關注跟我一起學~~~

擼文不易，莫要白瞟，三連走起~~~~