崇信县网站留言,wordpress如何数据转移,上海十大跨境电商排名,上海长城建设有限公司网站0x00 为什么要引入扩展方法 有的中间件功能比较简单#xff0c;有的则比较复杂#xff0c;并且依赖其它组件。除了直接用ApplicationBuilder的Use()方法注册中间件外#xff0c;还可以使用ApplicationBuilder的扩展方法UseMiddleware()注册中间件。这种情况下可以注册类型有的则比较复杂并且依赖其它组件。除了直接用ApplicationBuilder的Use()方法注册中间件外还可以使用ApplicationBuilder的扩展方法UseMiddleware()注册中间件。这种情况下可以注册类型这个方法会通过反射解析这个类型并把它包装成FuncReuqestDelegate,RequestDelegate然后调用Use()方法注册。 遇到这种情况一般直觉上是通过继承一个抽象类并实现其中的方法在写一个中间件。不过.NET Core不是这么做的。中间件类使用约定而不是继承来进行约束。这里说的约定就是约定原本的意思例如约定好了中间件类中必须包含一个叫Invoke的方法叫别的就不行有重载也不行。因为中间件类没有任何继承上的约束在注册过程中就是通过反射去寻找名字为Invoke的方法然后把它包装成RequestDelegate的。这篇文章就是要说一下写一个中间件类都有哪些约定以及中间件类的注册。 0x01 一个最简单的例子 先看一个中间件类的最简单的例子 上一篇文章中说过了中间件本质就是一个方法这个方法接收一个HttpContext参数返回Task。在上面这个中间件类中Invoke就是这个方法。为了能够调用下一个中间件当前中间件还需要保存下一个中间件的引用。这个引用是通过构造函数传进来的如果当前中间件不需要调用后面中间件的话这个引用完全可以不保存。如果要注册这个中间件我们可以这样做 但如果我们这个中间件比较复杂依赖很多其他模块那么我们在注册的时候需要构造依赖模块的实例并在中间件类的构造函数中把这些依赖传进去。这加强了中间件和依赖模块之间的耦合度。为了能减少这种耦合同时享受到依赖注入带来的便利提供了UseMiddlewareT扩展方法来注册中间件类T。 UseMiddleware扩展方法会找到上面中间件类中的Invoke方法创建上面类的实例在创建实例时遇到需要注入的类型会尝试注入然后把Invoke方法包装为ReuqestDelegate进而包装为FuncRequestDelegate,RequestDelegate然后通过ApplicatonBuilder的Use方法上篇文章讲过了注册到IListFuncRequestDelegaet,RequestDelegate中。 从上面的SimpleMiddleware我们可以看到这个类没有任何显示的继承关系那么我们在写一个中间件类时需要注意哪些约束呢我们只要看一下UseMiddleware注册中间件的过程就明白了。下面是对UseMiddleware()方法的分析对代码分析不感兴趣的可以跳过直接看后面的结论和测试。 0x02 扩展方法注册中间件类的过程 使用UseMiddlewareT扩展方法注册中间件类T主要包含以下几个关键步骤 1.找到中间件类的Invoke方法。UseMiddleware方法会通过反射获取注册的中间件类的所有public且非static的方法列表然后从其中找出名字叫Invoke的方法确认Invoke方法没有重载确认Invoke方法返回Task确认Invoke方法第一个参数是HttpContext最后这两个检查是为了能把Invoke方法包装为RequestDelegate。 2.选取最佳构造函数。把下一个中间件的引用next插入到从UseMiddleware传入的参数列表的第一个作为给定的参数列表。 然后获取中间件类的所有构造函数从给定的参数列表中依次取出参数和构造函数的参数进行类型匹配匹配最多的构造函数选为最佳构造函数。匹配相同的以代码中排在前面的构造函数为准这其中省略了很多匹配最佳构造函数的细节感兴趣的可以自行查看代码。 值得注意的是如果存在给定的参数列表中存在某个参数P在当前构造函数参数列表中找不到与之匹配的类型那么这个构造函数不能作为最佳构造函数。也就是说选中的最佳构造函数的参数列表必须要是给定参数列表的超集。刚刚上面也说了下一个中间件next被插入到了给定参数列表的第一个因此选中的最佳构造函数参数中必须包含参数RequestDelegate。如果所有构造函数都不包含RequestDelegate那么会抛出异常。 3.构造中间件类的实例。找到了最佳构造函数后接下来就使用该构造函数构造中间件类的实例。对于构造函数中的所有参数能够从给定的参数列表中找到类型匹配的从给定的参数列表中获取参数。从参数列表中找不到的则尝试从依赖注入容器中获取依赖注入容器中也找不到的检查是不是有默认值默认值也没有就抛出异常。 4.实例构造完成后如果Invoke方法只有一个参数HttpContext会把这个实例的Invoke方法包装为RequestDelegate进而包装为FuncRequestDelegate,RequestDelegate然后使用Use方法注册。如果有多个参数不符合RequestDelegate约束则对Invoke进行二次包装以符合RequestDelegate。在二次包装中会尝试从依赖注入容器中获取Invoke参数中的依赖。 0x03一些结论 下面总结一下中间件类的一些约定主要是基于对代码的理解有错误或不全的地方请指正。 关于中间件的方法 1.中间件的方法必须叫Invoke且为public非static。 2.Invoke方法第一个参数必须是HttpContext类型。 3.Invoke方法必须返回Task。 4.Invoke方法可以有多个参数除HttpContext外其它参数会尝试从依赖注入容器中获取。 5.Invoke方法不能有重载。 关于构造函数 1.构造函数必须包含RequestDelegate参数该参数传入的是下一个中间件。 2.构造函数参数中的RequestDelegate参数不是必须放在第一个可以是任意位置。 3.构造函数可以有多个参数参数会优先从给定的参数列表中找其次会从依赖注入容器中获取获取失败会尝试获取默认值都失败会抛出异常。 4.构造函数可以有多个届时会根据构造函数参数列表和给定的参数列表选择匹配度最高的一个。 个人建议真的仅仅是个人的一些建议 1.除及特殊情况外只保留一个构造函数以省去多余的构造函数匹配检查。 2.在构造函数中注入所需依赖而不是Invoke中。 3.关于构造函数参数的顺序把RequestDelegate放在第一个之后是UseMiddleware方法中给出的参数而且构造函数中参数顺序和给定参数列表中的顺序最好也相同然后是需要注入的参数最后是有默认值的参数。以上除了默认值参数必须放在最后外其余的顺序都不是必须的但按照上面的顺序会比较清晰而且能使实例创建的开销最小。 4.Invoke方法只保留一个HttpContext参数。这样可以省去对Invoke方法的二次包装。 5.进一步扩展ApplicationBuilder创建语义更加明确的方法代替Use/UseMiddleware例如UseMVC、UseStaticFiles。 其中1中所说的及特殊的情况我能想到的就是给UseMiddleware提供不同的参数列表进而匹配到不同的构造函数创建实例。具体使用场景没有想到。 0x04 测试 上篇文章中我们写过一个记录后面所有中间件耗时的中间件。当时直接用Use方法注册的。现在我们把它写为一个中间件类并且把计时功能写为一个StopWatch类并添加到依赖注入容器中。 下面是计时器类的代码 下面是中间件类的代码 下面是向依赖注入容器中添加StopWatch 下面是使用UseMiddleware扩展方法添加TimeMiddleware中间件代码 当然也可以不把StopWatch添加到依赖注入容器中而是在UserMiddleware方法中直接给出参数。 如果既在依赖注入容器中添加了StopWatch又在UseMiddleware注册时提供了StopWatch那么按照参数匹配顺序最终使用的是注册时提供的StopWatch。 运行一下可以看到与上篇文章同样的效果。 0x05 写在最后 UseMiddleware方法使注册中间件变得容易同事也减小了中间件和其它依赖模块间的耦合。不过不管哪种扩展方法最终都是通过Use方法实现中间件的注册。下一篇文章将写一下注册中间件的其它扩展方法Map、MapWhen和Run。 原文地址http://www.cnblogs.com/durow/p/5748124.html.NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
