dotNET兄弟会
专注.Net开源技术及跨平台开发&＃xff01;致力于构建完善的.Net开放技术文库&＃xff01;为.Net爱好者提供学习交流家园&＃xff01;
公众号
围绕DDD和ABP Framework两个核心技术&＃xff0c;后面还会陆续发布核心构件实现、综合案例实现系列文章&＃xff0c;敬请关注&＃xff01; ABP Framework 研习社&＃xff08;QQ群&＃xff1a;726299208&＃xff09; ABP Framework 学习及实施DDD经验分享&＃xff1b;示例源码、电子书共享&＃xff0c;欢迎加入&＃xff01;
系列文章
基于ABP落地领域驱动设计-01.全景图基于ABP落地领域驱动设计-02.聚合和聚合根的最佳实践和原则
仓储
仓储&＃xff08;接口&＃xff09;是一组集合的接口&＃xff0c;被领域层和应用层用来访问数据持久化系统&＃xff08;数据库&＃xff09;&＃xff0c;以读写业务对象&＃xff0c;业务对象通常是聚合。
仓储的通用原则
•在领域层中定义仓储接口&＃xff0c;在基础层中实现仓储接口&＃xff08;比如&＃xff1a;EntityFrameworkCore项目或MongoDB项目&＃xff09;•仓储不包含业务逻辑&＃xff0c;专注数据处理。•仓储接口应该保持 数据提供程序/ORM 独立性。举个例子&＃xff0c;仓储接口定义的方法不能返回 DbSet 对象&＃xff0c;因为该对象由 EF Core 提供&＃xff0c;如果使用 MongoDB 数据库则无法实现该接口。•为聚合根创建对应仓储&＃xff0c;而不是所有实体。因为子集合实体&＃xff08;聚合&＃xff09;应该通过聚合根访问。
仓储中不包含领域逻辑
虽然这个规则一开始看起来很好理解&＃xff0c;但在实际开发过程中&＃xff0c;很容易在不经意间将业务逻辑放到仓储中。
示例&＃xff1a;从仓储中获取 inactive 状态的 Issue
using System;
using System.Collections.Generic;
using System.Threading.Tasks;
using Volo.Abp.Domain.Repositories;
namespace IssueTracking.Issues
{
public interface IIssueRepository:IRepository
{
Task> GetInActiveIssuesAsync();
}
}
IIssueRepository 继承 IRepository 接口&＃xff0c;添加了 GetInActiveIssuesAsync() 方法。与之对应的聚合根类型是 Issue 类&＃xff1a;
public class Issue:AggregateRoot,IHasCreationTime
{
public bool IsClosed{get;private set;}
public Guid? AssignedUserId{get;private set;}
public DateTime CreationTime{get;private set;}
public DateTime? LastCommentTime{get;private set;}
}
规则要求我们&＃xff1a;仓储不应该知道业务规则&＃xff0c;那么问题来了&＃xff1a;什么是 inactive Issue&＃xff08;未激活的问题&＃xff09;&＃xff1f;这是业务规则。
为了更好地理解&＃xff0c;我们继续看看接口方法的实现&＃xff1a;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using IssueTracking.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore;
using Volo.Abp.Domain.Repositories.EntityFrameworkCore;
using Volo.Abp.EntityFrameworkCore;
namespace IssumeTracking.Issues
{
public class EfCoreIssueRepository:
EfCoreRepository,
IIssueRepository
{
public EfCoreIssueRepository(
IDbContextProvider dbContextProvider
):base(dbContextProvider)
{}
public async Task> GetInActiveIssueAsynce()
{
var daysAgo30&＃61;DateTime.Now.Subtract(TimeSpan.FromDays(30));
var dbSet &＃61;await GetDbSetAsync();
return await dbSet.Where(i&＃61;>
//打开状态
!i.IsClosed &&
//无分配人
i.AssingedUserId &＃61;&＃61;null &&
//创建时间在30天前
i.CreationTime //没有评论或最后一次评论在30天前
(i.LastCommentTime &＃61;&＃61; null || i.LastCommentTime ).ToListAsync();
}
}
}
在 GetInActiveIssueAsynce 实现方法中&＃xff0c;对于未激活的Issue 这条业务规则&＃xff0c;需要满足条件&＃xff1a;打开状态、未分配给任何人、创建超过30天、最近30天没有评论。
如果我们将业务规则隐含在仓储中&＃xff0c;当我们需要重复使用这个业务逻辑时&＃xff0c;问题就出现了。
举个例子&＃xff0c;在 Issue 实体中希望添加一个方法 bool IsInActive()&＃xff0c;用于检测 Issue 是否未激活状态。
看看如何实现&＃xff1a;
public class Issue:AggregateRoot,IHasCreationTime
{
public bool IsClosed {get;private set;}
public Guid? AssignedUserId{get;private set;}
public DateTime CreationTiem{get;private set;}
public DateTime? LastCommentTime{get;private set;}
//...
public bool IsInActive(){
var daysAgo30&＃61;DateTime.Now.Subtract(TimeSpan.FromDays(30));
return
//打开状态
!IsClosed &&
//无分配人
AssignedUserId &＃61;&＃61;null &&
//创建时间在30天前
CreationTime //无评论或最后一次评论在30天前
(LastCommentTime &＃61;&＃61; null || LastCommentTime }
}
我们不得不复制、粘贴、修改代码。如果对未激活的Issue 规则改变了怎么办&＃xff1f;我们应该记得同时更新这两个地方。这是业务逻辑重复&＃xff0c;代码的坏味道&＃xff0c;是相当危险的。
这个问题的一个很好的解决方案就是规约。
规约
规约是一个命名的、可重用的、可组合的和可测试的类&＃xff0c;用于根据业务规则过滤领域对象。
ABP框架提供了必要的基础设施&＃xff0c;以轻松创建规约并在你的应用程序代码中使用。让我们把 inactive Issue 非活动问题业务规则实现为一个规约类。
using System;
using System.Linq.Expressions;
using Volo.Abp.Specifications;
namespace IssueTracking.Issues
{
public class InActiveIssueSpecification:Specification
{
public override Expression> ToExpression()
{
var daysAgo30&＃61;DateTime.Now.Subtract(TimeSpan.FromDays(30));
return i &＃61;>
//打开状态
!i.IsClosed &&
//无分配人
i.AssingedUserId &＃61;&＃61;null &&
//创建时间超过30天
i.CreationTime //没有评论或最后评论超过30天
(i.LastCommentTime &＃61;&＃61; null || i.LastCommentTime }
}
}
Specification 基类可以帮助我们简单地创建规约类&＃xff0c;我们可以将仓储中的表达式移到规约中。
现在&＃xff0c;可以在 Issue 实体和 EfCoreIssueRepository 类中使用 InActiveIssueSpecification 规约。
在实体中使用规约
Specification类提供了一个IsSatisfiedBy方法&＃xff0c;如果给定的对象&＃xff08;实体&＃xff09;满足该规范&＃xff0c;则返回true。我们可以重新编写Issue.IsInActive方法&＃xff0c;如下所示&＃xff1a;
public class Issue:AggregateRoot,IHasCreationTime
{
public bool IsClosed{get;private set;}
public Guid? AssignedUserId{get;private set;}
public DateTime CreationTiem{get;private set;}
public DateTime? LastCommentTime{get;private set;}
//...
public bool IsInActive()
{
return new InActiveIssueSpecification().IsSatisfiedBy(this);
}
}
创建一个 InActiveIssueSpecification 新实例&＃xff0c;使用其 IsSatisfiedBy 方法&＃xff0c;进行规约验证。
在仓储中使用规约
首先&＃xff0c;修改仓储接口&＃xff1a;
public interface IIssueRepository:IRepository
{
Task> GetIssuesAsync(ISpecification spec);
}
将方法名 GetInActiveIssuesAsync 改为 GetIssuesAsync (命名更加简洁)&＃xff0c;接收一个规约对象参数。将规约判断的代码逻辑从仓储中移出之后&＃xff0c;我们不再需要定义不同的方法来获取不同条件下的Issue&＃xff0c;比如&＃xff1a;GetAssignedIssues(...) 获取已有分配人的问题列表&＃xff0c;GetLockedIssues(...) 获取已锁定问题列表 等。
修改仓储的实现&＃xff1a;
public class EfCoreIssueRepository:
EfCoreRepository,
IIssueRepository
{
public EfCoreIssueRepository(
IDbContextProvider dbContextProvider
):base(dbContextProvider)
{}
public async Task> GetIssuesAsync(ISpecification spec)
{
var dbSet &＃61; await GetDbSetAsync();
return await dbSet
.Where(spec.ToExpresion())
.ToListAsync();
}
}
ToExpression()方法返回一个表达式&＃xff0c;可以直接作为 Where 方法的参数传递&＃xff0c;实现实体过滤。
最后&＃xff0c;我们将规约实例&＃xff0c;传递给 GetIssuesAsync 方法:
public class IssueAppServie : ApplciationService,IIssueAppService
{
private readonly IIssueRepository _issueRepository;
public IssueAppService (IIssueRepository issueRepository)
{
_issueRepository &＃61; issueRepository;
}
public async Task DoItAsync()
{
var issues &＃61; await _issueRepository.GetIssuesAsync(
new InActiveIssueSpecification();
);
}
}
默认仓储
实际上&＃xff0c;你不需要创建自定义仓储就能使用规约。标准的IRepository 接口已经扩展 IQueryable 接口&＃xff0c;所以你可以直接使用标准的LINQ扩展方法。&＃xff08;非常帅气&＃xff01;&＃xff01;&＃xff01;&＃xff09;
public class IssueAppServie : ApplciationService,IIssueAppService
{
private readonly IRepository _issueRepository;
public IssueAppService (IRepository issueRepository)
{
_issueRepository &＃61; issueRepository;
}
public async Task DoItAsync()
{
var queryable &＃61; await _issueRepository.GetQueryableAsync();
var issues &＃61; AsyncExecuter.ToListAsync(
queryable.Where(new InActiveIssueSpecification())
);
}
}
AsyncExecuter是ABP框架提供的一个工具类&＃xff0c;用于使用异步LINQ扩展方法&＃xff08;比如这里的ToListAsync&＃xff09;&＃xff0c;而不依赖于EF Core NuGet 包。
组合规约
规范的一个强大的地方是它们是可以组合使用的。假设我们有另一个规约&＃xff0c;当问题 Issue 处于指定里程碑中时返回true。
public class MilestoneSpecification : Specification
{
public Guid MilestoneId{get;}
public MilestoneSpecification (Guid milestoneId)
{
MilestoneId &＃61; milestoneId;
}
public override Expression> ToExpression()
{
return i &＃61;> i.MilestoneId &＃61;&＃61; MilestoneId;
}
}
我们新定义了一个新的参数化规约&＃xff0c;和前面定义 InActiveIssueSpecification 不同。那么如何组合两个规约&＃xff0c;获取指定里程碑中未激活的 Issue&＃xff08;问题&＃xff09;呢&＃xff1f;
public class IssueAppServie : ApplciationService,IIssueAppService
{
private readonly IRepository _issueRepository;
public IssueAppService (IRepository issueRepository)
{
_issueRepository &＃61; issueRepository;
}
public async Task DoItAsync(Guid milesoneId)
{
var queryable &＃61; await _issueRepository.GetQueryableAsync();
var issues &＃61; AsyncExecuter.ToListAsync(
queryable.Where(new InActiveIssueSpecification()
.Add(new MilestoneSpecification(milestoneId))
.ToExpression()
)
);
}
}
示例中使用 Add 扩展方法组合规约&＃xff0c;还有更多的扩展方法&＃xff0c;比如&＃xff1a;Or(...) AndNot(...)。
学习帮助
围绕DDD和ABP Framework两个核心技术&＃xff0c;后面还会陆续发布核心构件实现、综合案例实现系列文章&＃xff0c;敬请关注&＃xff01;
ABP Framework 研习社&＃xff08;QQ群&＃xff1a;726299208&＃xff09; 专注 ABP Framework 学习及DDD实施经验分享&＃xff1b;示例源码、电子书共享&＃xff0c;欢迎加入&＃xff01;
京公网安备 11010802041100号