由于软件系统中可能有着不同的数据库,不同的ORM,仓储思想的本质是解耦它们。在ABP中具体的实现仓储接口定义在领域层,实现在基础设施层。仓储接口被领域层(比如领域服务)和应用层用来访问数据库,操作聚合根,聚合根就是业务单元。这篇文章主要分析怎么通过规约将业务逻辑从仓储实现中剥离出来,从而让仓储专注于数据处理。

一.业务需求

还是以Issue聚合根为例,假如有个业务规则是:判断是否是未激活的Issue,条件是打开状态、未分配给任何人、创建超过30天、最近30天没有评论。Issue聚合根如下:

二.在仓储中实现业务逻辑

该业务规则在基础设施层中实现如下:

namespace IssueTracking.Issues
{
public class EfCoreIssueRepository : EfCoreRepository<IssueTrackingDbContext, IssueTracking, Guid>, IIssueRepository
{
// 构造函数
public EfCoreIssueRepository(IDbContextProvider<IssueTrackingDbContext> dbContextProvider) : base(dbContextProvider)
{
} // 判断是否是未激活的Issue
public async Task<List<Issue>> GetInActiveIssuesAsync()
{
var daysAgo30 = DateTime.Now.Subtract(TimeSpan.FromDays(30)); var dbSet = await GetDbSetAsync();
return await dbSet.Where(i =>
// 打开状态
!i.IsClosed &&
// 无分配人
i.AssignedUserId == null &&
// 创建时间在30天前
i.CreationTime < daysAgo30 &&
// 没有评论或最后一次评论在30天前
(i.LastCommentTime == null || i.LastCommentTime < daysAgo30)
).toListAsync();
}
}
}

根据DDD中仓储的实践原则,肯定是不能将业务逻辑放在仓储实现中的,接下来使用规约的方式来解决这个问题。

三.使用规约实现业务逻辑

规约就是一种约定,规范来讲:规约是一个命名的、可重用的、可组合的和可测试的类,用于根据业务规则来过滤领域对象。通过ABP中的Specification规约基类创建规约类,将判断Issue是否激活这个业务规则实现为一个规约类如下:

namespace IssueTracking.Issues
{
public class InActiveIssueSpecification : Specification<Issue>
{
public override Expression<Func<Issue, bool>> ToExpression()
{
var daysAgo30 = DateTime.Now.Subtract(TimeSpan.FromDays(30));
return i =>
// 打开状态
!i.IsClosed &&
// 无分配人
i.AssignedUserId == null &&
// 创建时间在30天前
i.CreationTime < daysAgo30 &&
// 没有评论或最后一次评论在30天前
(i.LastCommentTime == null || i.LastCommentTime < daysAgo30)
}
}
}

接下来讲解在Issue实体和EfCoreIssueRepository类中如何使用InActiveIssueSpecification规约。

四.在实体中使用规约

规约是根据业务规则来过滤领域对象,Issue聚合根中的IsInActive()方法实现如下:

public class Issue : AggregateRoot<Guid>, IHasCreationTime
{
public bool IsClosed { get; private set; }
public Guid? AssignedUserId { get; private set; }
public DateTime CreateTime { get; private set; }
public DateTime? LastCommentTime { get; private set; } // 判断Issue是否未激活
public bool IsInActive()
{
return new InActiveIssueSpecification().IsSatisfiedBy(this);
}
}

创建一个InActiveIssueSpecification实例,使用它的IsSatisfiedBy()来进行规约验证。

五.在仓储中使用规约

领域层中的(自定义)仓储接口如下,GetIssuesAsync()接收一个规约对象参数:

public interface IIssueRepository : IRepository<Issue, Guid>
{
Task<List<Issue> GetIssuesAsync(ISpecification<Issue> spec);
}

基础设施层中的(自定义)仓储实现如下:

public class EfCoreIssueRepository: EfCoreRepository<IssueTrackingDbContext, EfCoreIssueRepository, Guid>, IIssueRepository
{
// 构造函数
public EfCoreIssueRepository(IDbContextProvider<IssueTrackingDbContext> dbContextProvider) : base(dbContextProvider)
{
} public async Task<List<Issue>> GetIssuesAsync(ISpecification<Issue> spec)
{
var dbSet = await GetDbSetAsync();
// 通过表达式实现Issue实体过滤
return await dbSet.Where(spec.ToExpression()).ToListAsync();
}
}
}

应用层使用规约如下,本质上就是新建一个规约实例,然后作为GetIssuesAsync()的参数:

public class IssueAppService : ApplicationService, IIssueAppService
{
private readonly IIssueRepository _issueRepository; // 构造函数
public IssueAppService(IIssueRepository issueRepository)
{
_issueRepository = issueRepository;
} public async Task DoItAsync()
{
// 在应用层通过仓储使用规约来过滤实体
var issues = await _issueRepository.GetIssuesAsync(new InActiveIssueSpecification());
}
}

六.在应用层中通过默认仓储来使用规约

上面是在应用层中通过自定义仓储来使用规约的,接下来讲解在应用层中通过默认仓储来使用规约:

public class IssueAppService : ApplicationService, IIssueAppService
{
private readonly IRepository<Issue, Guid> _issueRepository; // 构造函数
public IssueAppService(IRepository<Issue, Guid> issueRepository)
{
_issueRepository = issueRepository;
} public async Task DoItAsync()
{
var queryable = await _issueRepository.GetQueryableAsync();
// 简单理解,queryable就是查询出来的实体,然后根据规约进行过滤
var issues = AsyncExecuter.ToListAsync(queryable.Where(new InActiveIssueSpecification()));
}
}

说明:AsyncExecuter是ABP提供的一个工具类,用于使用异步LINQ拓展方法,而不依赖于EF Core NuGet包。

七.组合规约的使用

规约是可组合使用的,这样就变的很强大。比如,再定义一个规约,当Issue是指定里程碑是返回True。定义新的规约如下:

public class MilestoneSpecification : Specification<Issue>
{
public Guid MilestoneId { get; } // 构造函数
public MilestoneSpecification(Guid milestoneId)
{
MilestoneId = milestoneId;
} public override Expression<Func<Issue, bool>> ToExpression()
{
return x => x.MilestoneId == MilestoneId;
}
}

如果和上面定义的InActiveIssueSpecification规约组合,就可以实现业务逻辑:获取指定里程碑中未激活的Issue:

public class IssueAppService : ApplicationService, IIssueAppService
{
private readonly IRepository<Issue, Guid> _issueRepository; // 构造函数
public IssueAppService(IRepository<Issue, Guid> issueRepository)
{
_issueRepository = issueRepository;
} public async Task DoItAsync(Guid milestoneId)
{
var queryable = await _issueRepository.GetQueryableAsync();
// 组合规约的使用方法,除了Add扩展方法,还有Or()、And()、Not()等方法
var issues = AsyncExecuter.ToListAsync(
queryable.Where(new InActiveIssueSpecification()
.Add(new MilestoneSpecification(milestoneId))
.ToExpression()
)
);
}
}

参考文献:

[1]基于ABP Framework实现领域驱动设计:https://url39.ctfile.com/f/2501739-616007877-f3e258?p=2096 (访问密码: 2096)

基于ABP实现DDD--仓储实践的更多相关文章

  1. 基于ABP落地领域驱动设计-02.聚合和聚合根的最佳实践和原则

    目录 前言 聚合 聚合和聚合根原则 包含业务原则 单个单元原则 事务边界原则 可序列化原则 聚合和聚合根最佳实践 只通过ID引用其他聚合 用于 EF Core 和 关系型数据库 保持聚合根足够小 聚合 ...

  2. 基于ABP落地领域驱动设计-03.仓储和规约最佳实践和原则

    目录 系列文章 仓储 仓储的通用原则 仓储中不包含领域逻辑 规约 在实体中使用规约 在仓储中使用规约 组合规约 学习帮助 围绕DDD和ABP Framework两个核心技术,后面还会陆续发布核心构件实 ...

  3. 基于ABP落地领域驱动设计-04.领域服务和应用服务的最佳实践和原则

    目录 系列文章 领域服务 应用服务 学习帮助 系列文章 基于ABP落地领域驱动设计-00.目录和前言 基于ABP落地领域驱动设计-01.全景图 基于ABP落地领域驱动设计-02.聚合和聚合根的最佳实践 ...

  4. 基于ABP落地领域驱动设计-05.实体创建和更新最佳实践

    目录 系列文章 数据传输对象 输入DTO最佳实践 不要在输入DTO中定义不使用的属性 不要重用输入DTO 输入DTO中验证逻辑 输出DTO最佳实践 对象映射 学习帮助 系列文章 基于ABP落地领域驱动 ...

  5. 基于ABP实现DDD--领域服务、应用服务和DTO实践

      什么是领域服务呢?领域服务就是领域对象本身的服务,通常是通过多个聚合以实现单个聚合无法处理的逻辑. 一.领域服务实践 接下来将聚合根Issue中的AssignToAsync()方法[将问题分配给用 ...

  6. 基于ABP实现DDD--聚合和聚合根实践

      在下面的例子中涉及Repository.Issue.Label.User这4个聚合根,接下来以Issue聚合为例进行分析,其中Issue聚合是由Issue[聚合根].Comment[实体].Iss ...

  7. ABP(现代ASP.NET样板开发框架)系列之11、ABP领域层——仓储(Repositories)

    点这里进入ABP系列文章总目录 基于DDD的现代ASP.NET开发框架--ABP系列之11.ABP领域层——仓储(Repositories) ABP是“ASP.NET Boilerplate Proj ...

  8. ABP领域层——仓储(Repositories)

    ABP领域层——仓储(Repositories) 点这里进入ABP系列文章总目录 基于DDD的现代ASP.NET开发框架--ABP系列之11.ABP领域层——仓储(Repositories) ABP是 ...

  9. 基于ABP落地领域驱动设计-01.全景图

    什么是领域驱动设计? 领域驱动设计(简称:DDD)是一种针对复杂需求的软件开发方法.将软件实现与不断发展的模型联系起来,专注于核心领域逻辑,而不是基础设施细节.DDD适用于复杂领域和大规模应用,而不是 ...

随机推荐

  1. SpringBoot 读取配置文件数据

  2. 谁动了我的主机? 之活用History命令

    点击上方"开源Linux",选择"设为星标" 回复"学习"获取独家整理的学习资料! Linux系统下可通过history命令查看用户所有的历 ...

  3. 一文了解RPC框架原理

    点击上方"开源Linux",选择"设为星标" 回复"学习"获取独家整理的学习资料! 1.RPC框架的概念 RPC(Remote Proced ...

  4. Go 语言快速开发入门

    目录 需求 开发的步骤 linux下如何开发Go程序 MAC下如何开发Go程序 Golang执行流程分析 编译和运行说明 Go程序开发的注意事项 Go语言的转义字符(escapechar) Golan ...

  5. grafana v8.0+ 隐藏表格字段

    Select panel title → Inspect → Panel JSON Set "type" to "table-old" Apply The vi ...

  6. SpringBoot从0到0.7——序言

    SpringBoot从0到0.7-- 序言 最近做java代码审计发现很多地方看不懂,所以就开始学框架,自己做网站来了解网站的运行原理.函数.接口.参数等等,通过学习SpringBoot框架来从点到面 ...

  7. JavaScript与函数式编程

    JavaScript与函数式编程 绝大多数编程语言都会有函数的概念(或者说所有的?我不太确定),他们都可以做出类似的操作: function(x) { return x * x } 但是Javascr ...

  8. 第06组Alpha冲刺总结

    目录 1. 基本情况 2. 思考与总结 2.1. 设想和目标 2. 计划 3. 资源 4. 变更管理 5. 设计/实现 6. 测试/发布 7. 团队的角色,管理,合作 8. 总结 3. 敏捷开发 1. ...

  9. Win10 LTSC 2021 安装及相关bug解决

    Win10 LTSC 2021 安装及相关bug解决 目录 Win10 LTSC 2021 安装及相关bug解决 准备文件 系统安装 系统激活 修复CPU占用高和输入法显示bug 安装微软应用商店 推 ...

  10. Nastran的应变方向

    问题 近日使用Nastran做一个算例,在计算频响时发现:位移场是连续的,而应变场不连续.以某一频率处应变场为例,其上表面X.Y方向应变场分布如下图.此处关闭了云图的插值,所显示的为单元的应变,因此云 ...