一文說通Dotnet Core的中間件

時間 2020-06-06

標籤一文說通 dotnet core 中間件简体版

原文原文鏈接

前幾天，公衆號後臺有朋友在問Core的中間件，因此專門抽時間整理了這樣一篇文章。html

1、前言

中間件（Middleware）最初是一個機械上的概念，說的是兩個不一樣的運動結構中間的鏈接件。後來這個概念延伸到軟件行業，你們把應用操做系統和電腦硬件之間過渡的軟件或系統稱之爲中間件，比方驅動程序，就是一個典型的中間件。再後來，這個概念就泛開了，任何用來鏈接兩個不一樣系統的東西，都被叫作中間件。web

因此，中間件只是一個名詞，不用太在乎，實際代碼跟他這個詞，也沒太大關係。json

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

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

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

爲了防止不提供原網址的轉載，特在這裏加上原文連接：http://www.javashuo.com/article/p-wlqxqubg-dh.html微信

2、開發環境&基礎工程

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

$ 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

基礎工程搭建完成。async

3、建立第一個中間件

咱們先看下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進行調用。

4、中間件的短路

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

有時候，咱們但願中間件執行完成後就退出執行，而不進入下一個中間件。這時候，咱們能夠把await next.Invoke()從代碼中去掉。變成下面的形式：

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

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

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

這兩種形式，效果徹底同樣。

這種形式，咱們稱之爲短路，就是說在這個中間件執行後，程序即返回數據給客戶端，而不執行下面的中間件。

5、中間件的映射

有時候，咱們須要把一箇中間件映射到一個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。

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

可是，這兒有個問題：爲何咱們從各處文章裏看到的中間件，好像都不是這麼寫的？

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

下面，咱們就來講說變形。

6、變形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();

看着高大上了有沒有？

7、變形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());

8、變形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是注入參數的另外一種變形。我會在關於注入和依賴注入中詳細說明。

9、中間件的引入次序

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

通常來講，使用中間件的時候，能夠考慮如下規則：

實現Endpoint的中間件，應該放在最後，但要放在控制器引入的中間件以前。一般Endpoint中間件提供的是API或相似的內容，它會有Response的返回。而中間件在Response返回後，就不會調用Next了。
具備數據過濾內容的中間件，應該往前放，並且有個規則：當有過濾到規則外的狀況時，應該越早返回越好。

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

（全文完）