ABP开发框架先后端开发系列---（16）ABP框架升级最新版本的经验总结

有一小段时间没有持续升级ABP框架了，最近就因应客户的须要，把ABP框架进行全面的更新，因为咱们应用的ABP框架，基础部分仍是会使用官方的内容，所以升级的时候须要把官方基础ABP的DLL进行全面的更新，以及对应的引用DLL也同步更新才行。不过在升级过程当中仍是不少奇奇怪怪的问题，本篇随笔针对出现的状况进行一系列的总结，以便后面有一个对照参考吧。

一、最新案例源码和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最新地址进行更新，以下设置更新源。

在程序包源中添加：https://api.nuget.org/v3/index.json 

 

 响应速度相对快了一些，没有不常常的出问题了。

咱们若是须要单独更新某个项目的程序包，那么须要选择项目，选择【管理Nugget程序包】进入界面更新便可。以下界面所示。

通常状况下，咱们推荐对整个解决方案进行全面的程序包更新，以下选择解决方案，而后进入对应Nugget程序包管理界面更新便可。

这样的所有更新解决方案的程序包，若是可以顺利完成，那是皆大欢喜，不过可能会稍微慢一些。若是不行，只有逐个更新程序包了。

我以前选择这样的方式更新的时候，老是有一两个程序包更新出错，所以只有使用npm 控制台进行单独的升级了。

 

二、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客户端，界面以下所示。

 

登录启动后主体界面以下所示