中间件配置

不多墨迹，直接开整

观察Program.cs 发现项目的运行逻辑与Core3.1 与 5.0差异较大。

以前的IHostBuilder 已经不见了

取而代之的是一个新的类型 WebApplicationBuilder

F12 查看类的定义

 实锤了，这个类没见过

但是在类的属性中，发现了旧时.Net Core的 许多 “ 老朋友“

回到Program  观察代码，

注意到了服务与中间件的配置

服务注册使用的就是刚才预览ApplicationBuilder看到的属性IServicesCollection

但是观察请求管道的配置 app的类型为 WebApplicationBuilder

突然脑子转过来，刚刚预览WebApplicationBuilder时，它实现的接口列表

不正有旧时的IApplicationBuilder吗

这下全对上了

配置中间件，调用Build() 后的 use方法即可了

事实证明，是我想多了

这签名不对劲

原版use函数 应该是存在于Application 类型的内部的

 

观察IApplication  与原版无区别

这就奇了个怪了，为什么会无法调用类型内部的use方法？

查看WebApplication签名，看到了这种接口实现方式，

懂了

那看来要不就多一步，将WebApplication转换为IApplication进行中间件配置

或者 研究之前注意到的2个use 扩展方法了

学习别人代码的最高境界，当然是...翻源代码了

反正开源，不看白不看

发现扩展方法扩展的IApplication对象 所以走到了这里，

会自动将WebApplication转换为IApplication，就能间接的调用use方法了。

但是这两个use的代码，让人陷入沉思...

太绕了，让我们这些菜鸡怎么活

开始观察第一个use

它正是间接使用的，旧时的中间件配置方式。

缕清思路，经过换算

simpleNext 委托，其逻辑就是调用下一个中间件。

然后程序执行了传入的Func<HttpContext,Func<Task>,Task> 委托

上下文HttpContext与 调用下一个中间件的逻辑传入到了 该委托 middleware中

第一个能缕清，那第二个自然不在话下了

将上下文参数，与下一个中间件放入到了参数 middleware中

开始撸码！

现在配置中间件有了三种方式（本质上来说，都是最后一种）

先来个套娃压压惊

完成