ASP.NET Core 1.0中的管道-中间件模式
目录
ASP.NET Core 1.0借鉴了Katana项目的管道设计(Pipeline)。日志记录、用户认证、MVC等模块都以中间件(Middleware)的方式注册在管道中。显而易见这样的设计非常松耦合并且非常灵活,你可以自己定义任意功能的Middleware注册在管道中。这一设计非常适用于“请求-响应”这样的场景——消息从管道头流入最后反向流出。
在本文中暂且为这种模式起名叫做“管道-中间件(Pipeline-Middleware)”模式吧。
本文将描述”管道-中间件模式”的“契约式”设计和“函数式”设计两种方案。
一、什么是管道-中间件模式?
在此模式中抽象了一个类似管道的概念,所有的组件均以中间件的方式注册在此管道中,当请求进入管道后:中间件依次对请求作出处理,然后从最后一个中间件开始处理响应内容,最终反向流出管道。
二、契约式设计
契约式设计是从面向对象的角度来思考问题,根据管道-中间件的理解,中间件(Middleware)有两个职责:
1 2 3 4 5 | public interface IMiddleware { Request ProcessRequest(Request request); Response ProcessResponse(Response response); } |
管道(Pipeline)抽象应该能够注册中间件(Middleware):
1 2 3 4 5 6 7 8 9 | public interface IApplicationBuilder { void Use(IMiddleware middleware); void UseArrange(List<IMiddleware> middlewares); Context Run(Context context); } |
实现IApplicationBuilder:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 | public class ApplicationBuilder : IApplicationBuilder { public IWindsorContainer Container { get ; private set ; } private readonly List<IMiddleware> _middlewares; public ApplicationBuilder(IWindsorContainer container) { Contract.Requires(container!= null , "container!=null" ); _middlewares= new List<IMiddleware>(); Container = container; } public void Use(IMiddleware middleware) { Contract.Requires(middleware != null , "middleware!=null" ); _middlewares.Add(middleware); } public void UseArrange(List<IMiddleware> middlewares) { Contract.Requires(middlewares != null , "middlewares!=null" ); _middlewares.AddRange(middlewares); } public Context Run(Context context) { Contract.Requires(context!= null , "context!=null" ); var request=context.Request; var response=context.Response; foreach ( var middleware in _middlewares) { request = middleware.ProcessRequest(request); } _middlewares.Reverse(); foreach ( var middleware in _middlewares) { response = middleware.ProcessResponse(response); } return new Context(request,response); } } |
Run()方法将依次枚举Middleware并对消息的请求和响应进行处理,最后返回最终处理过的消息。
接下来需要实现一个Middleware:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | public class DefaultMiddleware:IMiddleware { public Request ProcessRequest(Request request) { request.Process( "default request" , "processed by defaultMiddleware" ); return request; } public Response ProcessResponse(Response response) { response.Process( "default response" , "processed by defaultMiddleware" ); return response; } } |
为了将Middleware注册进管道,我们还可以写一个扩展方法增加代码的可读性:
1 2 3 4 5 6 7 8 9 10 11 12 | public static void UseDefaultMiddleware( this IApplicationBuilder applicationBuilder) { applicationBuilder.Use<DefaultMiddleware>(); } public static void Use<TMiddleware>( this IApplicationBuilder applicationBuilder) where TMiddleware:IMiddleware { var middleware = applicationBuilder.Container.Resolve<TMiddleware>(); applicationBuilder.Use(middleware); } |
写个测试看看吧:
写第二个Middleware:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | public class GreetingMiddleware:IMiddleware { public Request ProcessRequest(Request request) { request.Process( "hello, request" , "processed by greetingMiddleware" ); return request; } public Response ProcessResponse(Response response) { response.Process( "hello, request" , "processed by greetingMiddleware" ); return response; } } |
编写测试:
三、函数式设计方案
此方案也是Owin和ASP.NET Core采用的方案,如果站在面向对象的角度,第一个方案是非常清晰的,管道最终通过枚举所有Middleware来依次处理请求。
站在函数式的角度来看,Middleware可以用Func<Context, Context>来表示,再来看看这张图:
一个Middleware的逻辑可以用Func<Func<Context, Context>, Func<Context, Context>>来表示,整个Middleware的逻辑可以用下面的代码描述:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | public Func<Func<Context, Context>, Func<Context, Context>> Process() { Func<Func<Context, Context>, Func<Context, Context>> middleware = next => { Func<Context, Context> process = context => { /*process request*/ next(context); /*process response*/ return context; }; return process; }; return middleware; } |
这一过程是理解函数式方案的关键,所有Middleware可以聚合为一个Func<Context,Context>,为了易于阅读,我们可以定义一个委托:
1 | public delegate Context RequestDelegate(Context context); |
给定初始RequestDelegate,聚合所有Middleware:
1 2 3 4 5 6 7 8 9 10 11 12 13 | public IApplication Build() { RequestDelegate request = context => context; _middlewares.Reverse(); foreach ( var middleware in _middlewares) { request = middleware(request); } return new Application(request); } |
自定义一个函数式Middleware:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | public class DefaultMiddleware:IMiddleware { public Func<RequestDelegate, RequestDelegate> Request() { Func<RequestDelegate, RequestDelegate> request = next => { return context => { context.Request.Process( "default request" , "processed by defaultMiddleware" ); next(context); context.Response.Process( "default response" , "processed by defaultMiddleware" ); return context; }; }; return request; } } |
所有代码提供下载:https://git.oschina.net/richieyangs/Pipeline.Middleware.git
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识(上)
· 阿里最新开源QwQ-32B,效果媲美deepseek-r1满血版,部署成本又又又降低了!
· 单线程的Redis速度为什么快?
· SQL Server 2025 AI相关能力初探
· 展开说说关于C#中ORM框架的用法!
· AI编程工具终极对决:字节Trae VS Cursor,谁才是开发者新宠?