前幾天，公眾號后臺有朋友在問Core的中間件，所以專門抽時間整理了這樣一篇文章，

一、前言

中間件（Middleware）最初是一個機械上的概念，說的是兩個不同的運動結構中間的連接件，后來這個概念延伸到軟體行業，大家把應用作業系統和電腦硬體之間過渡的軟體或系統稱之為中間件，比方驅動程式，就是一個典型的中間件，再后來，這個概念就泛開了，任何用來連接兩個不同系統的東西，都被叫做中間件，

所以，中間件只是一個名詞，不用太在意，實際代碼跟他這個詞，也沒太大關系，

中間件技術，早在.Net framework時期就有，只不過，那時候它不是Microsoft官方的東西，是一個叫OWIN的三方框架下的實作，到了.Net core，Microsoft才把中間件完整加到框架里來，

感覺上，應該是Core參考了OWIN的中間件技術（猜的，未求證），在實作方式上，兩個框架下的中間件沒什么區別，

下面，我們用一個實際的例子，來理清這個概念，

為了防止不提供原網址的轉載，特在這里加上原文鏈接：https://www.cnblogs.com/tiger-wang/p/13038419.html

二、開發環境&基礎工程

這個Demo的開發環境是：Mac + VS Code + Dotnet Core 3.1.2，

$ dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.1.201
 Commit:    b1768b4ae7

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.15
 OS Platform: Darwin
 RID:         osx.10.15-x64
 Base Path:   /usr/local/share/dotnet/sdk/3.1.201/

Host (useful for support):
  Version: 3.1.3
  Commit:  4a9f85e9f8

.NET Core SDKs installed:
  3.1.201 [/usr/local/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.App 3.1.3 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.3 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

首先，在這個環境下建立工程：

創建Solution

% dotnet new sln -o demo
The template "Solution File" was created successfully.

這次，我們用Webapi創建工程

% cd demo
% dotnet new webapi -o demo
The template "ASP.NET Core Web API" was created successfully.

Processing post-creation actions...
Running 'dotnet restore' on demo/demo.csproj...
  Restore completed in 179.13 ms for demo/demo.csproj.

Restore succeeded.

把工程加到Solution中

% dotnet sln add demo/demo.csproj

基礎工程搭建完成，

三、創建第一個中間件

我們先看下Demo專案的Startup.cs檔案：

namespace demo
{
    public class Startup
    {
        public Startup(IConfiguration configuration)
        {
            Configuration = configuration;
        }

        public IConfiguration Configuration { get; }

        /* This method gets called by the runtime. Use this method to add services to the container. */
        public void ConfigureServices(IServiceCollection services)
        {
            services.AddControllers();
        }

        /* This method gets called by the runtime. Use this method to configure the HTTP request pipeline. */
        public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }

            app.UseHttpsRedirection();

            app.UseRouting();

            app.UseAuthorization();

            app.UseEndpoints(endpoints =>
            {
                endpoints.MapControllers();
            });
        }
    }
}

這是Startup默認生成后的樣子（注意，不同的作業系統下生成的代碼會略有不同，但本質上沒區別），

其中，Configure是中間件的運行定義，ConfigureServices是中間件的引數設定注入，

我們在Configure方法里，加入一個簡單的中間件：

app.UseAuthorization();
/* 下面是加入的代碼 */
app.Use(async (context, next) =>
{
    /* your code */
    await next.Invoke();
    /* your code */
});
/********************/
app.UseEndpoints(endpoints =>
{
        endpoints.MapControllers();
});

在這個代碼中，app.Use是引入中間件的方式，而真正的中間件，是async (context, next)，這是一個delegate方法，

中間件方法的兩個引數，context是背景關系HttpContext，next指向下一個中間件，

其中，next引數很重要，中間件采用管道的形式執行，多個中間件，通過next進行呼叫，

四、中間件的短路

在前一節，我們看到了中間件的標準形式，

有時候，我們希望中間件執行完成后就退出執行，而不進入下一個中間件，這時候，我們可以把await next.Invoke()從代碼中去掉，變成下面的形式：

app.Use(async (context, next) =>
{
    /* your code */
});

對于這種形式，Microsoft給出了另一個方式的寫法：

app.Run(async context =>
{
    /* your code */
});

這兩種形式，效果完全一樣，

這種形式，我們稱之為短路，就是說在這個中間件執行后，程式即回傳資料給客戶端，而不執行下面的中間件，

五、中間件的映射

有時候，我們需要把一個中間件映射到一個Endpoint，用以對外提供簡單的API處理，這種時間，我們需要用到映射：

app.Map("/apiname", apiname => {
    app.Use(async (context, next) =>
    {
        /* your code */
        await next.Invoke();
    });  
});

此外，映射支持嵌套：

app.Map("/router", router => {
        router.Map("/api1name", api1Name => {
        app.Use(async (context, next) =>
        {
            /* your code */
            await next.Invoke();
        }); 
        });
      router.Map("/api2name", api2Name => {
        app.Use(async (context, next) =>
        {
            /* your code */
            await next.Invoke();
        });     
    });
})

對于這兩個嵌套的映射，我們訪問的Endpoint分別是/router/api1name和/router/api2name，

以上部分，就是中間件的基本內容，

但是，這兒有個問題：為什么我們從各處文章里看到的中間件，好像都不是這么寫的？

嗯，答案其實很簡單，我們看到的方式，也都是中間件，只不過，那些代碼，是這個中間件的最基本樣式的變形，

下面，我們就來說說變形，

六、變形1: 獨立成一個類

大多數情況下，我們希望中間件能獨立成一個類，方便控制，也方便程式撰寫，

這時候，我們可以這樣做：先寫一個類：

public class TestMiddleware
{
    private readonly RequestDelegate _next;

    public TestMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task Invoke(HttpContext context)
    {
        /* your code */
        await _next.Invoke(context);
    }
}

這個類里context和next和上面簡單形式下的兩個引數，型別和意義是完全一樣的，

下面，我們把這個類引入到Configure中：

app.UseMiddleware<TestMiddleware>();

注意，引入Middleware類，需要用app.UseMiddleware而不是app.Use，

app.Use引入的是方法，而app.UseMiddleware引入的是類，就這點區別，

如果再想高大上一點，可以做個Extensions：

public static class TestMiddlewareExtensions
{
    public static IApplicationBuilder UseTestMiddleware(this IApplicationBuilder app)
    {
        return app.UseMiddleware<TestMiddleware>();
    }
}

然后，在Configure中，就可以換成：

app.UseTestMiddleware();

看著高大上了有沒有？

七、變形2: 簡單引入引數

有時候，我們需要給在中間件初始化時，給它傳遞一些引數，

看類：

public class TestMiddleware
{
    private readonly RequestDelegate _next;
    private static object _parameter

    public TestMiddleware(RequestDelegate next, object parameter)
    {
        _next = next;
        _parameter = parameter;
    }

    public async Task Invoke(HttpContext context)
    {
        /* your code */
        await _next.Invoke(context);
    }
}

那相應的，我們在Configure中引入時，需要寫成：

app.UseMiddleware<TestMiddleware>(new object());

同理，如果我們用Extensions時：

public static class TestMiddlewareExtensions
{
    public static IApplicationBuilder UseTestMiddleware(this IApplicationBuilder app, object parameter)
    {
        return app.UseMiddleware<TestMiddleware>(parameter);
    }
}

同時，引入變為：

app.UseTestMiddleware(new object());

八、變形3: 依賴注入引數

跟前一節一樣，我們需要引入引數，這一節，我們用另一種更優雅的方式：依賴注入引數，

先創建一個interface：

public interface IParaInterface
{
    void someFunction();
}

再根據interface創建一個物體類：

public class ParaClass : IParaInterface
{
    public void someFunction()
    {
    }
}

引數類有了，下面建立中間件：

public class TestMiddleware
{
    private readonly RequestDelegate _next;
    private static IParaInterface _parameter

    public TestMiddleware(RequestDelegate next, IParaInterface parameter)
    {
        _next = next;
        _parameter = parameter;
    }

    public async Task Invoke(HttpContext context)
    {
        /* your code */
        /* Example: _parameter.someFunction(); */

        await _next.Invoke(context);
    }
}

因為我們要采用注入而不是傳遞引數，所以Extensions不需要關心引數：

public static class TestMiddlewareExtensions
{
    public static IApplicationBuilder UseTestMiddleware(this IApplicationBuilder app)
    {
        return app.UseMiddleware<TestMiddleware>();
    }
}

最后一步，我們在Startup的ConfigureServices中加入注入代碼：

services.AddTransient<IParaInterface, ParaClass>();

完成！

這個方式是Microsoft推薦的方式，

我在前文Dotnet core使用JWT認證授權最佳實踐中，在介紹JWT配置時，實際使用的也是這種方式，

中間件

app.UseAuthentication();

這是Microsoft已經寫好的認證中間件，我們只簡單做了參考，

注入引數

services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
            .AddJwtBearer(option =>
            {
                option.RequireHttpsMetadata = false;
                option.SaveToken = true;

                var token = Configuration.GetSection("tokenParameter").Get<tokenParameter>();

                option.TokenValidationParameters = new TokenValidationParameters
                {
                    ValidateIssuerSigningKey = true,
                    IssuerSigningKey = new SymmetricSecurityKey(Encoding.ASCII.GetBytes(token.Secret)),
                    ValidIssuer = token.Issuer,
                    ValidateIssuer = true,
                    ValidateAudience = false,
                    ClockSkew = TimeSpan.Zero,
                };
            });

這部分代碼，是我們注入的引數設定，其中，幾個方法又是Microsoft庫提供的Builder，

Builder是注入引數的另一種變形，我會在關于注入和依賴注入中詳細說明，

九、中間件的引入次序

中間件的引入次序，從代碼上來說沒有那么嚴格，就是說，某些型別的中間件交換次序不會有太大問題，

一般來說，使用中間件的時候，可以考慮以下規則：

實作Endpoint的中間件，應該放在最后，但要放在控制器引入的中間件之前，通常Endpoint中間件提供的是API或類似的內容，它會有Response的回傳，而中間件在Response回傳后，就不會呼叫Next了，
具有資料過濾內容的中間件，應該往前放，而且有個規則：當有過濾到規則外的情況時，應該越早回傳越好，

以這兩個規則來決定中間件的引入次序，就足夠了，

（全文完）