前幾天,公衆号背景有朋友在問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了。
- 具有資料過濾内容的中間件,應該往前放,而且有個規則:當有過濾到規則外的情況時,應該越早傳回越好。
以這兩個規則來決定中間件的引入次序,就足夠了。
(全文完)
微信公衆号:老王Plus 掃描二維碼,關注個人公衆号,可以第一時間得到最新的個人文章和内容推送 本文版權歸作者所有,轉載請保留此聲明和原文連結 |