其他分享
首页 > 其他分享> > 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