ABP开发框架前后端开发系列---（10）Web API调用类的简化处理
有一小段时间没有持续升级abp框架了，最近就因应客户的需要，把abp框架进行全面的更新，由于我们应用的abp框架，基础部分还是会使用官方的内容，因此升级的时候需要把官方基础abp的dll进行全面的更新，以及对应的引用dll也同步更新才行。不过在升级过程中还是很多奇奇怪怪的问题，本篇随笔针对出现的情况进行一系列的总结，以便后面有一个对照参考吧。
1、最新案例源码和nugget程序包更新
abp官方的基础模块更新速度还是很快的，一段时间过去，就跳过了几个版本号，我是在旧版本的基础上进行手动的nugget更新，但是基于vs的nugget总是更新卡顿，不知不觉就没有反应了，严重影响开发的效率。因此先从官方下载的demo案例中把相关部分源码进行更新。
官方的案例源码下载地址是：https://aspnetboilerplate.com/templates
1）最新案例源码结构和部分内容调整
我们从其中下载对应的源码，然后根据项目结构中的对应源码文件，使用beyond compare对比文件进行文件逐一对比，原则上除了个人扩展的部分，都以官方的源码做法为准即可。
目前abp官方最新的dll版本是5.3.0，可以下载的demo版本是5.2.0，它们应该差别不大。下载下来的aspnet-core部分的源码结构如下所示。
而我们的abp框架是在这个基础上进行一定的结构优化，以更加方便快速的开发，以及结合代码生成工具进行快速的使用。
我们的vs项目结构 如下所示。
以上是vs里面解决方案的项目结构，我根据项目之间的关系，整理了一个架构的图形，如下所示。
上图中，其中橘红色部分就是我们为各个层添加的类或者接口，分层上的序号是我们需要逐步处理的内容。
应用服务层是整个abp框架的灵魂所在，对内协同仓储对象实现数据的处理，对外配合web.core、web.host项目提供web api的服务，而web.core、web.host项目几乎不需要进行修改，因此应用服务层就是一个非常关键的部分，需要考虑对用户登录的验证、接口权限的认证、以及对审计日志的记录处理，以及异常的跟踪和传递，基本上应用服务层就是一个大内总管的角色，重要性不言而喻。
回顾了解一下我们改造过的abp开发框架的结构后，我们返回到版本升级的主体上来介绍。
目前我把vs的版本升级到最新，其.net framework支持4.8, 并单独安装了dotnetcore最新版本3.1，因此环境是最新的，而基础的abp 5.3.0也是采用了.net core3.1。
对比源码，我们可以发现，web.host和web.core项目里面已经有所差异，ihostingenvironment已经被抛弃使用，而采用dotnetcore最新对象iwebhostenvironment来替代了。
替换最新源码为
因此web.host项目中的module类也进行了调整。
相对应的web.core项目里面的module也同时进行调整了。
2）nugget程序包更新
nugget程序包的更新，原则上可以选择单个项目进行更新，或者选择整个解决方案进行程序包的更新，前者可能相应速度快一些，后者由于解决方案项目数量问题，可能会较慢。
我早期的基础abp版本是4.9，因此想一次性整个的解决方案的程序包进行更新，不过尝试多次，花了几个小时，都无法顺利进行项目的全部更新，于是单个项目进行更新，也非常慢。
于是也通过推荐采用nugget最新地址进行更新，如下设置更新源。
在程序包源中添加：
响应速度相对快了一些，没有不经常的出问题了。
我们如果需要单独更新某个项目的程序包，那么需要选择项目，选择【管理nugget程序包】进入界面更新即可。如下界面所示。
一般情况下，我们推荐对整个解决方案进行全面的程序包更新，如下选择解决方案，然后进入对应nugget程序包管理界面更新即可。
这样的全部更新解决方案的程序包，如果能够顺利完成，那是皆大欢喜，不过可能会稍微慢一些。如果不行，只有逐个更新程序包了。
我之前选择这样的方式更新的时候，总是有一两个程序包更新出错，因此只有使用npm 控制台进行单独的升级了。
2、abp框架基类封装接口命名调整
在更新abp基础模块的时候，发现abp的基础接口全部调整了命名，如原来的get变为getasync，getall变为 getallasync，delete变为了deleteasync，update变为了updateasync，create变为了createasync。
也就是说，他们全部采用了异步名称的命名规则，在异步方法后面全部加上了async作为标识。
我在之前模块介绍过abp框架的基础接口。iasynccrudappservice定义了几个通用的创建、更新、删除、获取单个对象和获取所有对象列表的接口，接口定义如下所示。
namespace abp.application.services
{
public interface iasynccrudappservice<tentitydto, tprimarykey, in tgetallinput, in tcreateinput, in tupdateinput, in tgetinput, in tdeleteinput> : iapplicationservice, itransientdependency
where tentitydto : ientitydto<tprimarykey>
where tupdateinput : ientitydto<tprimarykey>
where tgetinput : ientitydto<tprimarykey>
where tdeleteinput : ientitydto<tprimarykey>
{
task<tentitydto> create(tcreateinput input);
task delete(tdeleteinput input);
task<tentitydto> get(tgetinput input);
task<pagedresultdto<tentitydto>> getall(tgetallinput input);
task<tentitydto> update(tupdateinput input);
}
}
现在这些接口全部调整如下所示了。
namespace abp.application.services
{
public interface iasynccrudappservice<tentitydto, tprimarykey, in tgetallinput, in tcreateinput, in tupdateinput, in tgetinput, in tdeleteinput> : iapplicationservice, itransientdependency
where tentitydto : ientitydto<tprimarykey>
where tupdateinput : ientitydto<tprimarykey>
where tgetinput : ientitydto<tprimarykey>
where tdeleteinput : ientitydto<tprimarykey>
{
task<tentitydto> createasync(tcreateinput input);
task deleteasync(tdeleteinput input);
task<pagedresultdto<tentitydto>> getallasync(tgetallinput input);
task<tentitydto> getasync(tgetinput input);
task<tentitydto> updateasync(tupdateinput input);
}
}
那么这些我们都必须随着abp框架的调整也同时进行接口和对应类实现的调整了。
例如对应的异步applicationservice服务的基类封装，我们也需要调整对应的异步接口实现。
针对远程调用的apicaller接口和实现，我们也需要进行命名方面的统一调整，这样才能顺利进行异步接口的调用
我在之前随笔《abp开发框架前后端开发系列---（10）web api调用类的简化处理》有针对api调用层的简化处理做了说明，我们所有的api调用，基本都是通过统一的一个函数进行调用的。
统一调用处理的方法名称是doactionasync。
虽然由于前面介绍了应用服务层的接口很多接口增加了async的后缀字符，但是客户端通过url调用，这个async是不需要的，也就是需要移除，我们之前组装的url地址是根据函数名称，那么函数名称需要移除这个后缀的async字样了。
这样系统就顺利跑起来了。服务端界面如下所示。
我们启动winform客户端，界面如下所示。
登陆启动后主体界面如下所示