没有终结点在侦听可以接受消息的_asp.netcore3.xEndpoint终结点路由1基本介绍和使用...

我是从.net 4.5直接跳到.net core 3.x的&＃xff0c;感觉asp.net这套东西最初是从4.5中的owin形成的。
目前官方文档重点是讲路由&＃xff0c;没有特别说明与传统路由的区别&＃xff0c;本篇主要介绍终结点路由的相关概念和如何使用&＃xff0c;不会详细介绍路由&＃xff0c;这个参考官方文档就ok了。如果将来有机会研究到底层再深度剖析。

参考&＃xff1a;
https://docs.microsoft.com/zh-cn/aspnet/core/fundamentals/routing?view&＃61;aspnetcore-3.1
https://q.cnblogs.com/q/113644/ 
https://aregcode.com/blog/2019/dotnetcore-understanding-aspnet-endpoint-routing/

最初我们访问 http://www.abc.com/a.aspx时&＃xff0c;服务端是存在a.aspx这个文件的&＃xff0c;服务端根据此文件帮我们创建一个对应类的实例处理请求。
后来需求越来越复杂&＃xff0c;出现了路由&＃xff0c;目的是将请求地址与执行请求的处理器的直接关联&＃xff0c;变成映射关联&＃xff0c;映射规则由我们自己配置。
在asp.net core 3.x之前这个路由系统是包含在mvc内部的&＃xff0c;.net framework时代有个特殊的HttpModule来实现mvc&＃xff0c;路由系统也包含其中。.net core是由有个特殊的中间件来实现mvc的&＃xff0c;路由系统就包含在这个中间件中。
这种方式有个问题&＃xff0c;mvc只是一个中间件&＃xff0c;路由系统包含在其中&＃xff0c;如果我们希望在mvc中间件之后加入其它中间件&＃xff0c;其它中间件是无法(也许是不方便)访问路由相关信息的。
另外asp.net core并不是只有mvc&＃xff0c;还有webapi、blazor、signlR、接入gRpc等&＃xff0c;将来还有更多&＃xff0c;我们的路由系统能否提出来&＃xff0c;让所有框架都可以用&＃xff1f;

因此出现了终结点路由&＃xff0c;我们说路由的根本目的是将用户请求地址&＃xff0c;映射为一个请求处理器&＃xff0c;最简单的请求处理器可以是一个委托 Func&＃xff0c;也可以是mvc/webapi中某个controller的某个action&＃xff0c;所以从抽象的角度讲 一个终结点 就是一个处理请求的委托。由于mvc中action上还有很多attribute&＃xff0c;因此我们的终结点还应该提供一个集合&＃xff0c;用来存储与此请求处理委托的关联数据。
从抽象的角度可以简单理解为   一个终结点 &＃61; 处理请求的委托 &＃43; 与之关联的附加(元)数据。对应到mvc来理解的话 终结点 &＃61; action &＃43; 应用其上的attribute集合。但记住终结点是个抽象的概念&＃xff0c;并不只服务于mvc&＃xff0c;原理大概如下&＃xff1a;

1. 在程序启动前我们应该定义好程序中有哪些终结点&＃xff0c;当然不是我们手动一个个定义&＃xff0c;而是根据目标框架自动生成&＃xff0c;针对mvc来说的话可以自动将程序中与路由匹配的action转换成对应的终结点&＃xff0c;其它框架应该也有对应的方式&＃xff0c;反正最终我们所有用来处理请求的东东都变成了终结点。这步是在定义路由时自动完成的

2. 除了定义终结点我们还要定义 请求路径 与 终结点的对应关系&＃xff0c;将来请求抵达时才能匹配找到合适的终结点来处理我们的请求&＃xff0c;这步相当于定义路由

3. 我们还需要定义一个解析器&＃xff0c;当请求抵达时根据终结点与路径的对应关系找到终结点&＃xff0c;微软已定义好对应的中间件来表示这个解析器。

4. 最后我们需要定义一个中间件&＃xff0c;在上面的中间件执行后 我们可以拿到与当前请求匹配的终结点&＃xff0c;最终调用它的委托处理请求&＃xff0c;这个中间件就是mvc中间件

5. 到此asp.net core 3.x的中间件路由默认差不多就这样了&＃xff0c;此时我们可以定义自己的中间件&＃xff0c;放在步骤3后面&＃xff0c;拿到终结点做一些高级处理。微软定义的一些中间件也是这个套路

在通过vs默认模板创建asp.net core 3.x项目时&＃xff0c;在startup中会看到这样的代码

注册路由

看代码的第2行。它有如下3个任务

1. 创建终结点定义&＃xff0c;针对mvc来说会自动将程序中与路由格式匹配上的action转换为终结点。在第5行之后可以调试观察endpoints.DataSource属性&＃xff0c;生成好的终结点就在里面

2. 建立url与终结点的对应关系&＃xff0c;这种关系存在哪&＃xff1f;我也不晓得

3. 注册mvc中间件(它在将来请求抵达&＃xff0c;且之前有中间件解析得到与当前请求匹配的终结点后&＃xff0c;开始mvc旅程)

这里路由跟以前的写法差不多&＃xff0c;上面默认值啊、约束啊就去看官方文档吧。
创建终结点也会参照属性路由&＃xff0c;微软推荐webapi使用属性路由&＃xff0c;mvc使用传统路由。你会看到创建默认webapi项目时这样的 endpoints.MapControllers(); 

终结点进一步定制

默认情况下是根据定义的路由去找到匹配的action最后生成终结点&＃xff0c;这个生成终结点的过程我们是可以参与的&＃xff0c;具体办法是通过endpoints.MapControllerRoute的返回对象上调用相关扩展方法&＃xff0c;本质上是向终结点的创建过程加入一些委托&＃xff0c;将来创建终结点时&＃xff0c;这些委托将被调用&＃xff0c;代码如下&＃xff1a;

动态路由

app.UseEndpointsmvc时就说明了使用mvc和webapi了&＃xff0c;默认情况下一个action会创建一个对应的终结点&＃xff0c;请求抵达时匹配到终结点就直接执行了。但有时候我们希望自己控制一个请求过来时使用哪个controller的哪个action&＃xff0c;具体做法&＃xff1a;
定义一个类&＃xff0c;继承DynamicRouteValueTransformer&＃xff0c;并注册到ioc容器中&＃xff0c;最后调用一个扩展方法&＃xff0c;看代码&＃xff1a;

这样将来请求抵达时&＃xff0c;解析得到终结点时会调用我们的MyRouteValueTransformer&＃xff0c;我们可以获取已解析得到的路有数据&＃xff0c;然后选择替换/增加某些路由数据&＃xff0c;从而达到定制化

回退路由

默认情况下请求抵达时&＃xff0c;若没有找到匹配的终结点&＃xff0c;就直接404了&＃xff0c;我们希望当没有匹配到任何终结点时直接执行某个默认的终结点&＃xff0c;可以用如下方式&＃xff1a;

endpoints.MapFallbackToController("{controller}/{action}/{id?}", "kkk", "jj");

当请求抵达时&＃xff0c;如果没有匹配到任何终结点&＃xff0c;则默认执行jjController.kkk方法。可以想象得到此功能可能是通过动态路由实现的

还有几个相关的扩展方法&＃xff0c;有了上面的讲解&＃xff0c;估计你也能猜出是干嘛用的了。关于路由注册就暂时说这么多

自定义中间件提前拿到终结点数据

app.UseRouting();对应概述中的步骤3&＃xff0c;此扩展方法内部会注册一个中间件&＃xff0c;将来请求抵达时它会帮我们找到与当前请求匹配的终结点并存储在HttpContext中&＃xff0c;且匹配过程中解析得到的路由数据在Request.RouteValues中。我们可以在它后面加入自己的中间件