其他分享
首页 > 其他分享> > ABP VNext技术概述ABP VNext技术概述

ABP VNext技术概述ABP VNext技术概述

作者:互联网

 

在ABP VNext框架中处理和用户相关的多对多的关系

 

利用代码生成工具Database2Sharp生成ABP VNext框架项目代码    

 

在ABP VNext框架中对HttpApi模块的控制器进行基类封装    

 

ABP VNext框架基础知识介绍(2)--微服务的网关    

 

ABP VNext框架基础知识介绍(1)--框架基础类继承关系  

ABP VNext框架基础知识介绍(1)--框架基础类继承关系

 

在我较早的时候,就开始研究和介绍ABP框架,ABP框架相对一些其他的框架,它整合了很多.net core的新技术和相关应用场景,虽然最早开始ABP框架是基于.net framework,后来也全部转向拥抱.net core,而另一条线的ABP VNext则是定位从.net core开始的,基础类库以Volo.Abp开始。ABP框架和ABP VNext框架两者在基类和分层上,都很多几乎是一样的,不过ABP VNext框架是后来者,规避了很多前辈ABP框架的一些缺点,最明显的就是更加模块化(弊端就是管理的独立项目暴增),不过对于大项目来说,功能模块的切分也是必要的。ABP VNext是一个内容很丰富的架构体系,因此准备做一个系列介绍ABP VNext相关架构的知识,本篇随笔介绍它的一些框架基础类继承关系。

1、ABP VNext技术概述

ABP VNext框架如果不考虑在微服务上的应用,其集成使用的难度会降低一个层级,不过ABP VNext和ABP框架一样,基础内容都会设计很多内容,如数据库都支持Oracle、SQLServer、MySql、PostgreSQL、SQLite,都有利用Redis作为分布式缓存,使用RabbitMQ作为事件总线的消息处理方式,使用MongoDB的NoSQL类型数据库作为特殊数据的存储服务,使用Quartz/HangFire作为定时任务的处理等。如果考虑引入微服务的话,会更需要了解IdentityServer服务,以及了解Ocelot库管理网关,使用 Elasticsearch & Kibana 来存储和可视化日志 (使用Serilog写日志),有时候感觉引入框架并非一件轻松的事情,各种知识点一股脑的涌来。

我们开发复杂的系统,也是和建筑工人一样,一步步盖起房子来的,不同的是,有些人一块砖一块砖的盖,有些人采用预构件来构建,我们回到孩童的时候的思路,就是搭建积木的方式。

ABP VNext框架沿袭这种好习惯,把一些都简单化了,做起大项目来就更加方便了,类似搞一个乐高积木项目一样,不过我们约定了每个项目的基础分层部分,这样一来组装就标准化了。

如下面的一个项目,也可以当成它就是一个模块,和一个麻雀一样,五脏俱全,各个项目代表不同的功能,大家都这样做即可。

应用服务层:

Application.Contracts,包含应用服务接口和相关的数据传输对象(DTO)。
Application,包含应用服务实现,依赖于 Domain 包和 Application.Contracts 包。

领域层:
Domain.Shared,包含常量,枚举和其他类型. 
Domain 包含实体, 仓储接口,领域服务接口及其实现和其他领域对象,依赖于 Domain.Shared 包.

基础设施层:

EntityFrameworkCore,包含EF的ORM处理,使用仓储模式,实现数据的存储功能。

HTTP 层
HttpApi项目, 为模块开发REST风格的HTTP API。
HttpApi.Client项目,它将应用服务接口实现远程端点的客户端调用,提供的动态代理HTTP C#客户端的功能。

各个层的依赖关系如下图所示。

  

 我们把这些项目组成一个模块,即使这个模块只有一个表的处理功能,也是一个模块,它们构建成一个完整的模块内部生态层。

这样我们在以模块为基础单位,就可以单独开发,统一整合了,如下图所示。

 

 这样,我们以相关的模块组合,以及一些辅助工具,就构成了整套框架的一个生态基础。

 

针对ABP VNext的前后端完全分离模式,我们给BS的前端,只需要提供API服务,以及接入详细说明即可,而给Winform、WPF、Console等基于.net的终端,则可以利用HTTP层的HttpApi.Client项目的动态客户端方式,避免编写API的客户端代理即可。

我详细参考了ABP VNext的基础框架类,以及一些应用模块项目的代码,它们基本上是提供了很多底层的支持,上层模块的支持,很多是在其商业版中的功能,并没有出现在应用模块中,如我们常见的权限系统的实现,它模块里面只是提供了简单的的角色和用户信息管理(而且很不完善),而我们往往需要扩展开来实现详细的用户、组织机构、角色、岗位、菜单、权限等功能的管理,才能算是一个完整的权限系统,另外还需要封装字典模块、附件管理模块等一些基础模块应用,这些就需要我们自己实现它的功能了。

以权限管理模块为例,它们虽然提供及基础的DTO和领域对象,没有提供完整应用层的实现,作为一个完整的应用系统,肯定不行,需要利用框架进一步实现才可以整合在项目中使用。

 

 2、框架基础类继承关系

前面介绍了,本篇随笔作为系列的开篇,主要想介绍一下ABP VNext框架的一些基础类关系。

ABP VNext和ABP框架的基础类,虽然它们在项目管理上有所不同,不过它们的类关系层次继承关系,几乎没有太多的变化,有些一些层次上的调整而已。因此对于学习ABP或者ABP VNext框架来说,它们很多地方是共通的。

对于Application层来说,它是承接UI和领域层的中间层,因此它接收用户DTO对象,并且这些DTO对象为了和领域层的Entity层有映射关系,我们定义了一些基础类关系来协助它们,以方便DTO和Entity层之间的Mapping映射关系,从而通过约定方式承载系统的基础属性。

如ApplicationService层的相关DTO基类对象定义及继承关系如下图所示,其中右边是它们继承的接口,以及接口需要实现的属性信息。

注:上图ABP和ABP VNext框架,它们的基类定义和关系都是一样的。

而应用层有时候,需要对数据进行分页,并返回列表记录,那么下面的一些基类对象就是它的应用场景,通过定义分页信息和排序信息,可以让应用服务层获得相应的记录过滤,然后返回基于特定DTO对象的泛型列表,如下图所示。

 

注:上图ABP和ABP VNext框架,它们的基类定义和关系都是一样的。

ABP VNext框架的应用服务层类,提供了相关CRUD操作的基类,虽然我们有时候可以继承顶层ApplicationService进行开发,但是,为了方便,我们往往使用子类继承自CrudAppService,如下图所示。

首先定义相关自定义接口

复制代码
public interface IBookAppService : 
    ICrudAppService< //定义CRUD方法
        BookDto, //显示DTO
        Guid, //实体主键
        PagedAndSortedResultRequestDto, //用于分页排序获取列表
        CreateUpdateBookDto, //创建对象DTO
        CreateUpdateBookDto> //更新对象DTO
{
}
复制代码

然后实现该接口即可,如下所示。

复制代码
public class BookAppService : 
    CrudAppService<Book, BookDto, Guid, PagedAndSortedResultRequestDto,CreateUpdateBookDto, CreateUpdateBookDto>,
    IBookAppService
{
    public BookAppService(IRepository<Book, Guid> repository) 
        : base(repository)
    {
    }
}
复制代码

CrudAppService实现了ICrudAppService接口中声明的所有方法. 然后,你可以添加自己的自定义方法或覆盖和自定义实现.

相对于ABP VNext的应用服务层基类,它们ABP框架的基类有所差异 ,它们分离了同步和异步的基类,不过基本上都使用异步基类居多,继承关系图如下所示。

 它的服务层接口定义和接口实现的处理方式和ABP VNext的操作类似,就不再赘述了。

相对于前面介绍DTO层的基类定义,我们在框架的领域层也定义了类似的类和它的继承关系,和DTO一一对应,这样通过AutoMapping 的方式就可以自动处理他们的属性映射了,减少了很多繁琐的代码处理。

领域层的实体类关系和前面DTO关系类似,如下所示。

 

"聚合是域驱动设计中的一种模式.DDD的聚合是一组可以作为一个单元处理的域对象.例如,订单及订单系列的商品,这些是独立的对象,但将订单(连同订单系列的商品)视为一个聚合通常是很有用的。

如果是聚合根,如商品、订单和订单明细的关系场景,就可以应用到,ABP不强制你使用聚合根,实际上你可以使用上面定义的Entity类。

它们和领域的实体关系整合起来是一张关系图,如下所示。

 

 这个在基类部分,和ABP框架有所差异,ABP VNext框架中的聚合根增加了扩展属性的接口定义和实现,以及领域事件的处理接口,如下所示。

 

 它们的部分基类代码如下所示

复制代码
namespace Volo.Abp.Domain.Entities
{
    [Serializable]
    public abstract class AggregateRoot : BasicAggregateRoot,
        IHasExtraProperties,
        IHasConcurrencyStamp
    {
        public virtual ExtraPropertyDictionary ExtraProperties { get; protected set; }

        [DisableAuditing]
        public virtual string ConcurrencyStamp { get; set; }

        protected AggregateRoot()
        {
            ConcurrencyStamp = Guid.NewGuid().ToString("N");
            ExtraProperties = new ExtraPropertyDictionary();
            this.SetDefaultsForExtraProperties();
        }

        public virtual IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
        {
            return ExtensibleObjectValidator.GetValidationErrors(
                this,
                validationContext
            );
        }
    }
复制代码

 

 而ABP 框架的聚合根部分,除了基类有所差异,处理一些特殊的信息外,基本上也是类似的。

 

 以上就是ABP VNext的一些基类和关系图,希望能够促进我们了解ABP VNext框架的神秘之处,解开它的面纱。

 如果你对ABP框架的知识点有兴趣,可以参考《ABP框架使用》,如果对于ABP框架VUE&Element前端开发有兴趣,可以参考《循序渐进VUE+Element》部分内容。

 

主要研究技术:代码生成工具、会员管理系统、客户关系管理软件、病人资料管理软件、Visio二次开发、酒店管理系统、仓库管理系统等共享软件开发
专注于Winform开发框架/混合式开发框架Web开发框架Bootstrap开发框架微信门户开发框架的研究及应用
  转载请注明出处:
撰写人:伍华聪  http://www.iqidi.com 

标签:VNext,DTO,框架,ABP,概述,模块,基类
来源: https://www.cnblogs.com/Leo_wl/p/15973366.html