ABP开发框架前后端开发系列---(16)ABP框架升级最新版本的经验总结

简介: ABP开发框架前后端开发系列---(16)ABP框架升级最新版本的经验总结

有一小段时间没有持续升级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客户端,界面如下所示。

 

登陆启动后主体界面如下所示

 

专注于代码生成工具、.Net/.NetCore 框架架构及软件开发,以及各种Vue.js的前端技术应用。著有Winform开发框架/混合式开发框架、微信开发框架、Bootstrap开发框架、ABP开发框架、SqlSugar开发框架等框架产品。
 转载请注明出处:撰写人:伍华聪  http://www.iqidi.com
   

标签: ABP框架使用

相关文章
|
资源调度 关系型数据库 MySQL
若依框架部署从零开始2023版(前后端分离)
电脑最近重装了一次系统,目前什么都没有安装,记录一下从零开始部署前后端分离版本的若依框架系统先去官网把若依源码拉下来。
753 0
|
5月前
|
开发框架 前端开发 JavaScript
ABP开发框架的技术点分析(1)
ABP开发框架的技术点分析(1)
|
4月前
|
前端开发 程序员 API
从后端到前端的无缝切换:一名C#程序员如何借助Blazor技术实现全栈开发的梦想——深入解析Blazor框架下的Web应用构建之旅,附带实战代码示例与项目配置技巧揭露
【8月更文挑战第31天】本文通过详细步骤和代码示例,介绍了如何利用 Blazor 构建全栈 Web 应用。从创建新的 Blazor WebAssembly 项目开始,逐步演示了前后端分离的服务架构设计,包括 REST API 的设置及 Blazor 组件的数据展示。通过整合前后端逻辑,C# 开发者能够在统一环境中实现高效且一致的全栈开发。Blazor 的引入不仅简化了 Web 应用开发流程,还为习惯于后端开发的程序员提供了进入前端世界的桥梁。
481 0
|
开发框架 小程序 JavaScript
【小程序开发框架选型】7大小程序开发框架,哪一个更适合你?
小程序越来越流行,微信小程序、百度小程序、支付宝小程序、头条小程序等等不断涌入我们的生活,随着小程序的火爆,各种小程序框架不断出现。小程序开发公认的7个小程序开发框架: 原生、uni-app、taro、mpvue、wepy、chameleon、remax。各有利弊。
991 0
|
开发框架 .NET 中间件
浅入ABP(1):搭建基础结构的 ABP 解决方案
浅入ABP(1):搭建基础结构的 ABP 解决方案
166 0
浅入ABP(1):搭建基础结构的 ABP 解决方案
|
开发框架 JSON 前端开发
浅入ABP(2):添加基础集成服务
浅入ABP(2):添加基础集成服务
675 0
浅入ABP(2):添加基础集成服务
|
JavaScript 前端开发 API
「免费开源」基于Vue和Quasar的crudapi前端SPA项目实战之模块管理(十四)
通过配置的方式可以零代码实现表单管理功能,但是所有表单都没有分类,如果表单数量很多的情况下不方便查找,因此本文主要介绍表单模块管理相关内容。属于同一类型的表单可以添加到同一个模块,比如字典相关的表建立“字典”模块,用户相关的表建立“用户管理”模块,模块在首页直接展示,用户可以快速的操作对应的表单。
249 0
「免费开源」基于Vue和Quasar的crudapi前端SPA项目实战之模块管理(十四)
|
JSON 前端开发 API
C#使用Xamarin开发可移植移动应用进阶篇(10.综合演练,来一份增删改查CRUD)
原文:C#使用Xamarin开发可移植移动应用进阶篇(10.综合演练,来一份增删改查CRUD) 前言 系列目录 C#使用Xamarin开发可移植移动应用目录 源码地址:https://github.
1039 1
下一篇
DataWorks