快速部署业务类为webapi服务
接着前一篇博文,将接口快速打包固定请求格式,不需要修改代码,可以自动完成接口调用,实际上就是生成了一个接口的代理类。
那么仅仅是接口请求代理,没有服务端怎么行?所以需要将实现接口的类部署为webapi的控制器。
这个时候ABP就登场了,原理需要查看官方文档。ABP就是实现了快速生成部署。
我就不说ABP的东西了,官方文档可以任意查阅。
因为ABP作为一种开源组件,集成的东西太多太全,作为小企业中的我们,复杂,不容易上手,所以打算跳过这个东西。
我需要的是把实现了业务接口的类部署成webapi即可,没有其它功用。
后面找到一个已经研究过的项目Dynamic Web AP。项目地址:https://github.com/dotnetauth/Panda.DynamicWebApi.git
作者博文地址:https://www.cnblogs.com/stulzq/p/11007770.html。
最近花时间看了看,其实就是asp中的AOP接口使用,只是我买平时开放用WebApi,没有采用。
研究了作者的东西,我感觉小项目是可以用的,原作者叫动态webapi,其实简单说就是webRPC.
我用netcore3用了下,有个别地方有差异。基本原理是合适的。
主要有2点:
1.根据自己的约定,设置某个类是控制器
2.根据判断的控制器类,按照aspnet core约束,修改其中的内容,让aspnet core将它认定为webapi.
这里我就不讲原作者的代码了,感兴趣的可以去看,我只讲我的,我们的差不多。
认定接口类是控制器的方法:
继承ControllerFeatureProvider类,该类就是mvc验证是控制器的类,里面有个方法IsController,返回true就表明当前类型是控制器。
我的代码中提供了配置,传入一个Fun类型委托,如果原来的判断不成功,就调用该委托,通过自定义方法检查是否是控制器。
注意:比较老版本该类是不能使用的,只能继承该类的实现接口,把源码抄过来。新版本才可以,把IsController方法修改成了虚拟方法。
修改约束的方法:
实现IApplicationModelConvention接口,逐步修改各级约束。其实按照aspnet core的使用。
就是按照信息处理。
最后创建的URL路由:api/域名称/控制器名称/方法名称。
里面的控制器名称可以设置,提供了配置方法。目前考虑不要侵入代码。
所以我的代码中提供配置,根据配置的名称分别查找控制器的常量,静态属性或者字段,获取值来设置控制器URL中的名称。
同理,版本信息,所属域都是这样。
简单的介绍就这样完了。
提供的建议:
如果你要按照这种解决方案,将实现接口的业务类快速部署,那么给一点点建议。
关于控制器名称,一种方式是固化格式,方便前端修改调用,例如,实现的业务类名称=接口名称+“Bil”,这样每个接口对应的控制器名称就有了。前端格式化实现请求就有路径了。另外可以在接口中添加常量,静态变量来设置,这样就符合后端实现了。
前端格式化实现时就可以反射获取接口中的值类设置URL.当前最后不要在业务接口中直接使用,而是让每一个业务接口都继承一个api的转用接口,在这个专用接口上面添加特性,常量,静态变量。这样就可以实现无代码侵入了。这部分工作在我的代码中没有,需要用户自己定义使用。ABP和原作者就是在代码中已经定义了,所以必须有特性或者类,而我的没有。这也是为什么他们需要添加特性或者继承,就是以此来判断控制器类或者名称,域的。
差不多了,慢慢看吧。
附带一点点说明:
netcore3有一些变化,把一些组件移除了,做第三方存在了,所以对应是有变化的。这里涉及的是JSON格式化,微软使用了自己定义的。System.Text.Json.而不是原来的第三方组件了。
所以Swagger也要使用最新的预览版,低版本报错。
我的示例用的是NSwag。使用NSwag.AspNetCore包。
最后说说我封装的库使用方法:
Startup中,
services.AddWebApiAssembly(null);//添加程序集
services.AddWebApiDirectory(null);//添加程序集目录
添加程序集,就是一般说的将控制器剥离的方式,内部封装了。
services.AddDynamicWebApi(new DynamicWebApiOptions() { ControllerFeature=(P)=> {
if (P.GetInterface(typeof(ICall).Name) == null)
{
return false;
}
return true;
} });
添加动态处理组件,就是封装整个过程的库,算是中间件吧。里面的ControllerFeature就是判断控制器的委托。