一文说通Dotnet Core的中间件
前几天，公众号后台有朋友在问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 扫描二维码，关注个人公众号，可以第一时间得到最新的个人文章和内容推送 本文版权归作者所有，转载请保留此声明和原文链接 |
