*****理解ASP.NET Core - 中间件(Middleware)，以及中间件的生命周期*****

理解ASP.NET Core - 中间件(Middleware)中间件 先借用微软官方文档的一张图： 可以看到，中间件实 - 掘金

ASP.NET Core管道详解[4]: 中间件委托链 - Artech - 博客园

 

　　通过调用IApplicationBuilder接口的UseMiddleware扩展方法注册的是一个按照约定规则定义的中间件类型，由于中间件实例是在应用初始化时创建的，这样的中间件实际上是一个与当前应用程序具有相同生命周期的Singleton对象。但有时我们希望中间件对象采用Scoped模式的生命周期，即要求中间件对象在开始处理请求时被创建，在完成请求处理后被回收释放。

　　如果需要后面这种类型的中间件，就需要让定义的中间件类型实现IMiddleware接口。如下面的代码片段所示，IMiddleware接口定义了唯一的InvokeAsync方法，用来实现对请求的处理。对于实现该方法的中间件类型来说，它可以利用输入参数得到针对当前请求的HttpContext上下文，还可以得到用来向后续中间件分发请求的RequestDelegate对象。

 

 

 

基于约定的中间件

“约定大于配置”，先来个约法三章：

1. 拥有公共（public）构造函数，且该构造函数至少包含一个类型为RequestDelegate的参数
2. 拥有名为Invoke或InvokeAsync的公共（public）方法，必须包含一个类型为HttpContext的方法参数，且该参数必须位于第一个参数的位置，另外该方法必须返回Task类型。
3. 构造函数中的其他参数可以通过依赖注入（DI）填充，也可以通过UseMiddleware传参进行填充。
   • 通过DI填充时，只能接收 Transient 和 Singleton 的DI参数。这是由于中间件是在应用启动时构造的（而不是按请求构造），所以当出现 Scoped 参数时，构造函数内的DI参数生命周期与其他不共享，如果想要共享，则必须将Scoped DI参数添加到Invoke/InvokeAsync来进行使用。
   • 通过UseMiddleware传参时，构造函数内的DI参数和非DI参数顺序没有要求，传入UseMiddleware内的参数顺序也没有要求，但是我建议将非DI参数放到前面，DI参数放到后面。（这一块感觉微软做的好牛皮）
4. Invoke/InvokeAsync的其他参数也能够通过依赖注入（DI）填充，可以接收 Transient、Scoped 和 Singleton 的DI参数。

基于工厂的中间件

优势：

• 按照请求进行激活。这个就是说，上面基于约定的中间件实例是单例的，但是基于工厂的中间件，可以在依赖注入时设置中间件实例的生命周期。
• 使中间件强类型化（因为其实现了接口IMiddleware）

你有没有想过当我们调用UseMiddleware时，它是如何工作的呢？事实上，UseMiddleware扩展方法会先检查中间件是否实现了IMiddleware接口。 如果实现了，则使用容器中注册的IMiddlewareFactory实例来解析该IMiddleware的实例（这下你知道为什么称为“基于工厂的中间件”了吧）。如果没实现，那么就使用基于约定的中间件逻辑来激活中间件。

作者：xiaoxiaotank
链接：https://juejin.cn/post/7064560090094764062
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。