換個角度學習ASP.NET Core中間件

中間件真面目

關於ASP.NET Core中間件是啥，簡單一句話描述就是：用來處理HTTP請求和響應的一段邏輯，而且能夠決定是否把請求傳遞到管道中的下一個中間件！

上面只是概念上的一種文字描述，那問題來了，中間件在程序中究竟是個啥❓

一切仍是從IApplicationBuilder提及，沒錯，就是你們熟悉的Startup類裏面那個Configure方法裏面的那個IApplicationBuilder（有點繞😵,抓住重點就行）。

IApplicationBuilder，應用構建者，聽這個名字就能感覺它的核心地位，ASP.NET Core應用就是依賴它構建出來，看看它的定義：

public interface IApplicationBuilder
{
    //...省略部分代碼...
    IApplicationBuilder Use(Func<RequestDelegate, RequestDelegate> middleware);
    RequestDelegate Build();
}

Use方法用來把中間件添加到應用管道中，此時咱們已經看到中間件的真面目了，原來是一個委託，輸入參數是RequestDelegate，返回也是RequestDelegate，其實RequestDelegate仍是個委託，以下：

public delegate Task RequestDelegate(HttpContext context);

還記得中間件是幹嗎的嗎？是用來處理http請求和響應的，即對HttpContext的處理，這裏咱們能夠看出來原來中間件的業務邏輯就是封裝在RequestDelegate裏面。

總結一下：

middleware就是Func<RequestDelegate, RequestDelegate>，輸入的是下一個中間件的業務處理邏輯，返回的就是當前中間件的業務處理邏輯，並在其中決定要不要調用下箇中間件！咱們代碼實現一箇中間件看看（可能和咱們平時用的不太同樣，但它就是中間件最原始的形式！）:

//Startup.Configure方法中
Func<RequestDelegate, RequestDelegate> middleware1 = next => async (context) =>
           {
               //處理http請求

               Console.WriteLine("do something before invoke next middleware in middleware1");
               //調用下一個中間件邏輯，固然根據業務實際狀況，也能夠不調用，那此時中間件管道調用到此就結束來了！

               await next.Invoke(context);
               Console.WriteLine("do something after invoke next middleware in middleware1");
           };
//添加到應用中           

app.Use(middleware1);

跑一下瞅瞅，成功執行中間件！

IIS Express is running.
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
      Content root path: E:\vs2019Project\WebApplication3\WebApplication3
do something before invoke next middleware in middleware1
do something after invoke next middleware in middleware1

中間件管道

經過上面咱們有沒有注意到，添加中間時，他們都是一個一個獨立的被添加進去，而中間件管道就是負責把中間件串聯起來，實現下面的一箇中間件調用流轉流程：

如何實現呢？這個就是IApplicationBuilder中的Build的職責了，再次看下定義：

public interface IApplicationBuilder
{
 //...省略部分代碼...
 IApplicationBuilder Use(Func<RequestDelegate, RequestDelegate> middleware);
 RequestDelegate Build();
}

Build方法一頓操做猛如虎，主要幹一件事把中間件串聯起來，最後返回了一個 RequestDelegate，而這個就是咱們添加的第一個中間件返回的RequestDelegate，

看下框架默認實現：

//ApplicationBuilder.cs
public RequestDelegate Build()
        {
            RequestDelegate app = context =>
            {
                // If we reach the end of the pipeline, but we have an endpoint, then something unexpected has happened.
                // This could happen if user code sets an endpoint, but they forgot to add the UseEndpoint middleware.
                var endpoint = context.GetEndpoint();
                var endpointRequestDelegate = endpoint?.RequestDelegate;
                if (endpointRequestDelegate != null)
                {
                    var message =
                        $"The request reached the end of the pipeline without executing the endpoint: '{endpoint.DisplayName}'. " +
                        $"Please register the EndpointMiddleware using '{nameof(IApplicationBuilder)}.UseEndpoints(...)' if using " +
                        $"routing.";
                    throw new InvalidOperationException(message);
                }

                context.Response.StatusCode = 404;
                return Task.CompletedTask;
            };

            foreach (var component in _components.Reverse())
            {
                app = component(app);
            }

            return app;
        }

• Build方法裏面定義了一個 RequestDelegate ，做爲最後一個處理邏輯，例如返回404。

• _components存儲着添加的全部中間件

• 中間件管道調度順序，就是按照中間添加的順序調用，因此中間件的順序很重要，很重要，很重要！

• 遍歷_components，傳入next RequestDelegate，獲取當前RequestDelegate，完成管道構建！

中間件使用

在此以前，仍是提醒下，中間件最原始的使用姿式就是

IApplicationBuilder Use(Func<RequestDelegate, RequestDelegate> middleware);

下面使用的方式，都是對此方式的擴展！

Lamda方式

大多數教程裏面都提到的方式，直接上代碼：

//擴展方法
//IApplicationBuilder Use(this IApplicationBuilder app, Func<HttpContext, Func<Task>, Task> middleware)
app.Use(async (context, next) =>
           {
               Console.WriteLine("in m1");
               await next.Invoke();
               Console.WriteLine("out m1");
           });

擴展方法簡化了中間件的使用，這個裏面就只負責寫核心邏輯，而後擴展方法中把它包裝成Func<RequestDelegate, RequestDelegate>類型進行添加，不像原始寫的那樣複雜，咱們看下這個擴展方法實現，哈，原來就是一個簡單封裝！咱們只要專一在middleware裏面寫核心業務邏輯便可。

public static IApplicationBuilder Use(this IApplicationBuilder app, Func<HttpContext, Func<Task>, Task> middleware)
        {
            return app.Use(next =>
            {
                return context =>
                {
                    Func<Task> simpleNext = () => next(context);
                    return middleware(context, simpleNext);
                };
            });
        }

若是咱們定義中間件做爲終端中間件(管道流轉此中間件就結束了，再也不調用後面的中間件)使用時，上面只要不調用next便可。

固然咱們還有另一個選擇，本身使用擴展Run方法，傳入的參數就是RequestDelegate，仍是上代碼：

//擴展方法
//public static void Run(this IApplicationBuilder app, RequestDelegate handler);
app.Run(async (context) =>
            {
                Console.WriteLine("in m3");
                await context.Response.WriteAsync("test22");
                Console.WriteLine("out m3");
            });

到此，咱們有沒有發現上面的方式有些弊端，只能處理下簡單邏輯，若是要依賴第三方服務，那可怎麼辦？

定義中間件類方式

使用中間件類，咱們只要按照約定的方式，即類中包含InvokeAsync方法，就能夠了。

使用類後，咱們就能夠注入咱們須要的第三方服務，而後完成更復雜的業務邏輯，上代碼

//定義第三方服務
public interface ITestService
    {
        Task Test(HttpContext context);
    }
    public class TestService : ITestService
    {
        private int _times = 0;
        public Task Test(HttpContext context)
        {
           return context.Response.WriteAsync($"{nameof(TestService)}.{nameof(TestService.Test)} is called {++_times} times\n");
        }
    }

//添加到IOC容器
public void ConfigureServices(IServiceCollection services)
        {


            services.AddTransient<ITestService, TestService>();
        }

//中間件類，注入ITestService
public class CustomeMiddleware1
    {
        private int _cnt;
        private RequestDelegate _next;
        private ITestService _testService;
        public CustomeMiddleware1(RequestDelegate next, ITestService testService)
        {
            _next = next;
            _cnt = 0;
            _testService = testService;
        }
        public async Task InvokeAsync(HttpContext context)
        {
            await _testService?.Test(context);
            await context.Response.WriteAsync($"{nameof(CustomeMiddleware1)} invoked {++_cnt} times");

        }
    }

//添加中間件，仍是一個擴展方法，預知詳情，請看源碼
app.UseMiddleware<CustomeMiddleware1>();

運行一下，跑出來的結果以下，完美！

等一下，有沒有發現上面有啥問題？？？❓

明明ITestService是以Transient註冊到容器裏面，應該每次使用都是新實例化的，那不該該被顯示被調用 15 次啊！！！

這個時候咱們應該發現，咱們上面的全部方式添加的中間件的生命週期其實和應用程序是一致的，也就是說是隻在程序啓動的時候實例化一次！因此這裏第三方的服務，而後以Transient方式註冊到容器，但在中間件裏面變現出來就是一個單例效果，這就爲何咱們不建議在中間件裏面注入DbContext了，由於DbContext咱們通常是以Scoped來用的，一次http請求結束，咱們就要釋放它！

若是咱們就是要在中間件裏面是有ITestService，並且仍是Transient的效果，怎麼辦？

實現IMiddleware接口

//接口定義
public interface IMiddleware
{    
    ask InvokeAsync(HttpContext context, RequestDelegate next);
}

//實現接口
public class CustomeMiddleware : IMiddleware
    {
        private int _cnt;
        private ITestService _testService;
        public CustomeMiddleware(ITestService testService)
        {
            _cnt = 0;
            _testService = testService;
        }
        public async Task InvokeAsync(HttpContext context, RequestDelegate next)
        {
            await _testService?.Test(context);
            await context.Response.WriteAsync($"{nameof(CustomeMiddleware)} invoked {++_cnt} times");

        }
    }

//添加中間件
app.UseMiddleware<CustomeMiddleware>();

運行一下，結果報錯了... ，提示CustomeMiddleware沒有註冊！

InvalidOperationException: No service for type 'WebApplication3.CustomeMiddleware' has been registered.

經過報錯信息，咱們已經知道，若是實現了IMiddleware接口的中間件，他們並非在應用啓動時就實例化好的，而是每次都是從IOC容器中獲取的，其中就是IMiddlewareFactory

來解析出對應類型的中間件的（內部就是調用IServiceProvider），瞭解到此，咱們就知道，此類中間件此時是須要以service的方式註冊到IOC容器裏面的，這樣中間件就能夠根據註冊時候指定的生命週期方式來實例化，從而解決了咱們上一節提出的疑問了！好了，咱們註冊下中間件服務

public void ConfigureServices(IServiceCollection services)
        {
            services.AddTransient<CustomeMiddleware>();
            services.AddTransient<ITestService, TestService>();
        }

再次屢次刷新請求，返回都是下面的內容

TestService.Test is called 1 times
CustomeMiddleware invoked 1 times

結語

中間件存在這麼多的使用方式，每個存在都是爲了解決實際需求的，當咱們瞭解這些背景知識後，在後面本身使用時，就能更加的靈活！