ABP开发框架前后端开发系列---(16)ABP框架升级最新版本的经验总结
原文:https://www.cnblogs.com/wuhuacong/p/12447044.html
有一小段时间没有持续升级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最新地址进行更新,如下设置更新源。
在程序包源中添加:https://api.nuget.org/v3/index.json
响应速度相对快了一些,没有不经常的出问题了。
我们如果需要单独更新某个项目的程序包,那么需要选择项目,选择【管理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客户端,界面如下所示。
登陆启动后主体界面如下所示
posted on 2020-10-30 14:34 springsnow 阅读(697) 评论(0) 编辑 收藏 举报