ASP.NET Core处理管道的深入理解

using System.Threading.Tasks; public class CustomResponseHeader: IMiddleware { // 使用构造函数完成服务依赖的定义 public CustomResponseHeader() { } public Task InvodeAsync(HttpContextSample context, RequestDelegate next) { context.Output.AppendLine("From Custom Middleware."); return next(context); } }

这更好看懂了，可是它怎么变成那个 Func<RequestDelegate, RequestDelegate> 呢？

在演示程序中使用该中间件。

List<Func<RequestDelegate, RequestDelegate>> _components = new List<Func<RequestDelegate, RequestDelegate>>(); _components.Add(middleware1); _components.Add(middleware2); var middleware3 = new CustomResponseHeader(); Func<RequestDelegate, RequestDelegate> middleware3 = next => { return (HttpContextSample context) => { // 中间件 3 的处理 var result = middleware3.InvodeAsync(context, next); return result; }; }; _components.Add(middleware3);

这样开发者可以使用熟悉的对象方式开发中间件，而系统内部自动根据你的定义，生成出来一个 Func<RequestDelegate, RequestDelegate> 形式的中间件。

ASP.NET Core 使用该类型中间件的形式如下所示，这是提供了一个方便的扩展方法来完成这个工作。

.UseMiddleware<CustomResponseHeader>();

按照约定定义中间件

除了实现 IMiddleware 这个接口，还可以使用约定方式来创建中间件。

按照约定定义中间件不需要实现某个预定义的接口或者继承某个基类，而是需要遵循一些约定即可。约定主要体现在如下几个方面：

中间件需要一个公共的有效构造函数，该构造函数必须包含一个类型为 RequestDelegate 类型的参数。它代表后继的中间件处理函数。构造函数不仅可以包含任意其它参数，对 RequestDelegate 参数出现的位置也没有任何限制。

针对请求的处理实现再返回类型为 Task 的 InvokeAsync() 方法或者同步的 Invoke() 方法中，方法的第一个参数表示当前的请求上下文 HttpContext 对象，对于其他参数，虽然约定并未进行限制，但是由于这些参数最终由依赖注入框架提供，所以，相应的服务注册必须提供。

构造函数和 Invoke/InvokeAsync 的其他参数由依赖关系注入 (DI) 填充。

using System.Threading.Tasks; public class RequestCultureMiddleware { private readonly RequestDelegate _next; public RequestCultureMiddleware (RequestDelegate next) { _next = next; } public async Task InvokeAsync (HttpContextSample context) { context.Output.AppendLine("Middleware 4 Processing."); // Call the next delegate/middleware in the pipeline await _next (context); } }

在演示程序中使用按照约定定义的中间件。

（编辑：源码门户网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!