In front of the essay " before and after the end of ABP development framework developed series --- (2) initial presentation framework ", I introduced the project organization of the ABP application framework, as well as projects in various areas like code organization layer, so based database applications simplified. Benpian essays further frame of the original base project ABP certain improvement, reduction processing business layer area, while the field object AutoMapper detached tag instead of using the configuration file, the DTO interface definition and application-layer peeling, so that we use more convenience and simplicity, binding quickly generate corresponding code to make a layered matting subsequent use code generation tool.
1) improve the structure of ABP project
ABP's official website documents inside custom storage class is not recommended (unless suitable excuse to find the need to do), and business management class domain objects, but also had reservations about that situation if only one application entry (my main consideration Web API priority), and therefore the field of business objects can not customize, so we thought the whole application framework ABP is very clear, at the same time using the standard storage class, basically you can solve most of the data manipulation. The purpose of reducing custom business management class is to reduce complexity, while we pulled out and DTO objects mapping between domain objects to the proper service layer AutoMapper Profile defined in the file, which can simplify the DTO does not depend on the field of objects, DTO application service layer and the interface can be shared with similar Winform, UWP / WPF, console programs, etc., to avoid duplicate definitions, this is similar to our traditional Entity layer. Here I emphasize that this improvement ABP frame, layered and did not change throughout the application framework calls the rule of ABP, just as simple as possible and keep the public content.
Solution project structure shown in the following improvements.
These are the project structure inside VS solutions, based on the relationship between my project, put together a graphics architecture, as shown below.
The figure above, where the orange part is that we added for each class or interface layer, the hierarchical number is what we need gradual process, we have to interpret what each class one by one or content interface.
2) hierarchical project code
Based on field-driven processing us, the first step is to define the relationship between the entity and the field of database tables, I am here to watch the dictionary module to be introduced, for example.
首先我们创建字典模块里面两个表，两个表的字段设计如下所示。
而其中我们Id是业务对象的主键，所有表都是统一的，两个表之间都有一部分重复的字段，是用来做操作记录的。
这个里面我们可以记录创建的用户ID、创建时间、修改的用户ID、修改时间、删除的信息等。
1）领域对象
例如我们定义字典类型的领域对象，如下代码所示。
[Table("TB_DictType")] public class DictType : FullAuditedEntity<string> { /// <summary> /// 类型名称 /// </summary> [Required] public virtual string Name { get; set; } /// <summary> /// 字典代码 /// </summary> public virtual string Code { get; set; } /// <summary> /// 父ID /// </summary> public virtual string PID { get; set; } /// <summary> /// 备注 /// </summary> public virtual string Remark { get; set; } /// <summary> /// 排序 /// </summary> public virtual string Seq { get; set; } }
其中FullAuditedEntity<string>代表我需要记录对象的增删改时间和用户信息，当然还有AuditedEntity和CreationAuditedEntity基类对象，来标识记录信息的不同。
字典数据的领域对象定义如下所示。
[Table("TB_DictData")] public class DictData : FullAuditedEntity<string> { /// <summary> /// 字典类型ID /// </summary> [Required] public virtual string DictType_ID { get; set; } /// <summary> /// 字典大类 /// </summary> [ForeignKey("DictType_ID")] public virtual DictType DictType { get; set; } /// <summary> /// 字典名称 /// </summary> [Required] public virtual string Name { get; set; } /// <summary> /// 字典值 /// </summary> public virtual string Value { get; set; } /// <summary> /// 备注 /// </summary> public virtual string Remark { get; set; } /// <summary> /// 排序 /// </summary> public virtual string Seq { get; set; } }
这里注意我们有一个外键DictType_ID，同时有一个DictType对象的信息，这个我们使用仓储对象操作就很方便获取到对应的字典类型对象了。
[ForeignKey("DictType_ID")] public virtual DictType DictType { get; set; }
2）EF的仓储核心层
这个部分我们基本上不需要什么改动，我们只需要加入我们定义好的仓储对象DbSet即可，如下所示。
public class MyProjectDbContext : AbpZeroDbContext<Tenant, Role, User, MyProjectDbContext> { //字典内容 public virtual DbSet<DictType> DictType { get; set; } public virtual DbSet<DictData> DictData { get; set; } public MyProjectDbContext(DbContextOptions<MyProjectDbContext> options) : base(options) { } }
通过上面代码，我们可以看到，我们每加入一个领域对象实体，在这里就需要增加一个DbSet的对象属性，至于它们是如何协同处理仓储模式的，我们可以暂不关心它的机制。
3）应用服务通用层
这个项目分层里面，我们主要放置在各个模块里面公用的DTO和应用服务接口类。
例如我们定义字典类型的DTO对象，如下所示，这里涉及的DTO，没有使用AutoMapper的标记。
/// <summary> /// 字典对象DTO /// </summary> public class DictTypeDto : EntityDto<string> { /// <summary> /// 类型名称 /// </summary> [Required] public virtual string Name { get; set; } /// <summary> /// 字典代码 /// </summary> public virtual string Code { get; set; } /// <summary> /// 父ID /// </summary> public virtual string PID { get; set; } /// <summary> /// 备注 /// </summary> public virtual string Remark { get; set; } /// <summary> /// 排序 /// </summary> public virtual string Seq { get; set; } }
字典类型的应用服务层接口定义如下所示。
public interface IDictTypeAppService : IAsyncCrudAppService<DictTypeDto, string, PagedResultRequestDto, CreateDictTypeDto, DictTypeDto> { /// <summary> /// 获取所有字典类型的列表集合(Key为名称，Value为ID值） /// </summary> /// <param name="dictTypeId">字典类型ID，为空则返回所有</param> /// <returns></returns> Task<Dictionary<string, string>> GetAllType(string dictTypeId); /// <summary> /// 获取字典类型一级列表及其下面的内容 /// </summary> /// <param name="pid">如果指定PID，那么找它下面的记录，否则获取所有</param> /// <returns></returns> Task<IList<DictTypeNodeDto>> GetTree(string pid); }
从上面的接口代码，我们可以看到，字典类型的接口基类是基于异步CRUD操作的基类接口IAsyncCrudAppService，这个是在ABP核心项目的Abp.ZeroCore项目里面，使用它需要引入对应的项目依赖
而基于IAsyncCrudAppService的接口定义，我们往往还需要多定义几个DTO对象，如创建对象、更新对象、删除对象、分页对象等等。
如字典类型的创建对象DTO类定义如下所示，由于操作内容没有太多差异，我们可以简单的继承自DictTypeDto即可。
/// <summary> /// 字典类型创建对象 /// </summary> public class CreateDictTypeDto : DictTypeDto { }
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); } }
而由于这个接口定义了这些通用处理接口，我们在做应用服务类的实现的时候，都往往基于基类AsyncCrudAppService，默认具有以上接口的实现。
同理，对于字典数据对象的操作类似，我们创建相关的DTO对象和应用服务层接口。
/// <summary> /// 字典数据的DTO /// </summary> public class DictDataDto : EntityDto<string> { /// <summary> /// 字典类型ID /// </summary> [Required] public virtual string DictType_ID { get; set; } /// <summary> /// 字典名称 /// </summary> [Required] public virtual string Name { get; set; } /// <summary> /// 指定值 /// </summary> public virtual string Value { get; set; } /// <summary> /// 备注 /// </summary> public virtual string Remark { get; set; } /// <summary> /// 排序 /// </summary> public virtual string Seq { get; set; } } /// <summary> /// 创建字典数据的DTO /// </summary> public class CreateDictDataDto : DictDataDto { }
/// <summary> /// 字典数据的应用服务层接口 /// </summary> public interface IDictDataAppService : IAsyncCrudAppService<DictDataDto, string, PagedResultRequestDto, CreateDictDataDto, DictDataDto> { /// <summary> /// 根据字典类型ID获取所有该类型的字典列表集合(Key为名称，Value为值） /// </summary> /// <param name="dictTypeId">字典类型ID</param> /// <returns></returns> Task<Dictionary<string, string>> GetDictByTypeID(string dictTypeId); /// <summary> /// 根据字典类型名称获取所有该类型的字典列表集合(Key为名称，Value为值） /// </summary> /// <param name="dictType">字典类型名称</param> /// <returns></returns> Task<Dictionary<string, string>> GetDictByDictType(string dictTypeName); }
4）应用服务层实现
应用服务层是整个ABP框架的灵魂所在，对内协同仓储对象实现数据的处理，对外配合Web.Core、Web.Host项目提供Web API的服务，而Web.Core、Web.Host项目几乎不需要进行修改，因此应用服务层就是一个非常关键的部分，需要考虑对用户登录的验证、接口权限的认证、以及对审计日志的记录处理，以及异常的跟踪和传递，基本上应用服务层就是一个大内总管的角色，重要性不言而喻。
应用服务层只需要根据应用服务通用层的DTO和服务接口，利用标准的仓储对象进行数据的处理调用即可。
如对于字典类型的应用服务层实现类代码如下所示。
/// <summary> /// 字典类型应用服务层实现 /// </summary> [AbpAuthorize] public class DictTypeAppService : MyAsyncServiceBase<DictType, DictTypeDto, string, PagedResultRequestDto, CreateDictTypeDto, DictTypeDto>, IDictTypeAppService { /// <summary> /// 标准的仓储对象 /// </summary> private readonly IRepository<DictType, string> _repository; public DictTypeAppService(IRepository<DictType, string> repository) : base(repository) { _repository = repository; } /// <summary> /// 获取所有字典类型的列表集合(Key为名称，Value为ID值） /// </summary> /// <returns></returns> public async Task<Dictionary<string, string>> GetAllType(string dictTypeId) { IList<DictType> list = null; if (!string.IsNullOrWhiteSpace(dictTypeId)) { list = await Repository.GetAllListAsync(p => p.PID == dictTypeId); } else { list = await Repository.GetAllListAsync(); } Dictionary<string, string> dict = new Dictionary<string, string>(); foreach (var info in list) { if (!dict.ContainsKey(info.Name)) { dict.Add(info.Name, info.Id); } } return dict; } /// <summary> /// 获取字典类型一级列表及其下面的内容 /// </summary> /// <param name="pid">如果指定PID，那么找它下面的记录，否则获取所有</param> /// <returns></returns> public async Task<IList<DictTypeNodeDto>> GetTree(string pid) { //确保PID非空 pid = string.IsNullOrWhiteSpace(pid) ? "-1" : pid; List<DictTypeNodeDto> typeNodeList = new List<DictTypeNodeDto>(); var topList = Repository.GetAllList(s => s.PID == pid).MapTo<List<DictTypeNodeDto>>();//顶级内容 foreach(var dto in topList) { var subList = Repository.GetAllList(s => s.PID == dto.Id).MapTo<List<DictTypeNodeDto>>(); if (subList != null && subList.Count > 0) { dto.Children.AddRange(subList); } } return await Task.FromResult(topList); } }
我们可以看到，标准的增删改查操作，我们不需要实现，因为已经在基类应用服务类AsyncCrudAppService，默认具有这些接口的实现。
而我们在类的时候，看到一个声明的标签[AbpAuthorize]，就是对这个服务层的访问，需要用户的授权登录才可以访问。
5）Web.Host Web API宿主层
如我们在Web.Host项目里面启动的Swagger接口测试页面里面，就是需要先登录的。
这样我们测试字典类型或者字典数据的接口，才能返回响应的数据。
由于篇幅的关系，后面在另起篇章介绍如何封装Web API的调用类，并在控制台程序和Winform程序中对Web API接口服务层的调用，以后还会考虑在Ant-Design（React）和IVIew（Vue）里面进行Web界面的封装调用。
这两天把这一个月来研究ABP的心得体会都尽量写出来和大家探讨，同时也希望大家不要认为我这些是灌水之作即可。