工作单元模式中的 EF Core 封装

Question

我在加入 DDD 和 EF Core 时遇到问题。

我正在使用 DDD 架构制作项目。作为数据访问级别，我使用来自here 的通用工作单元模式。

public interface IUnitOfWork
{
    IRepository<TDomain> Repository<TDomain>() where TDomain : class;
}

public interface IRepository<TDomain>
{
    TDomain Get(Expression<Func<TDomain, bool>> predicate);
}

我使用 EF Core 实现这些接口。

我有一些包含 2 个类的域模型

public class MainClass
{
    public int Id { get; set; }

    public List<RelatedItem> Items { get; set; }
}

public class RelatedItem
{
    public int Id { get; set; }

    public MainClass Parent { get; set; }

    public DateTime Date { get; set; }

    public string SomeProperty { get; set; }
}

在我的项目MainClass 的现实生活中收集了数百个RelatedItems。为了执行某些操作，每个请求我只需要一个RelatedItem 和某个日期。可以通过Items属性搜索来完成。

在工作单元中封装 EF Core 的性能我必须从数据库中显式加载带有相关项目的实体，因为业务登录层对 UnitOfWork 存储库的实现一无所知。但是这个操作很慢。

所以我决定创建MainClassService，它注入costructor unitOfWork 并有一个只返回一个RelatedItem 的方法，它工作正常。

public class MainClassService
{
    IUnitOfWork unitOfWork;

    public MainClassService(IUnitOfWork unitOfWork)
    {
        this.unitOfWork = unitOfWork ?? throw new ArgumentNullException();
    }

    public RelatedItem GetRelatedItemByDate(int mainClassId, DateTime date)
    {
        return unitOfWork.Repository<RelatedItem>().Get(c => c.Parent.Id == mainClassId && c.Date == date);
    }
}

因此，由于 EF Core，我无法直接使用属性 Items，但由于 DDD 架构，我应该使用它们。

而我的问题是：使用这样的结构可以吗？

Answer 1

从您的问题看来，MainClass 是一个聚合根，RelatedItem 是一个嵌套实体。此设计决策应基于必须保护的业务规则/不变量。当 Aggregate 需要变异时，必须从存储库中完全加载，即 Aggregate 根及其所有嵌套实体和值对象在执行变异命令之前必须在内存中，无论它有多大。

此外，将基础设施服务注入聚合（或嵌套实体）不是一个好习惯。如果您需要这样做，那么您必须重新考虑您的架构。

因此，从我所写的内容中，您可以看到问题仅在您尝试改变聚合时才会出现。如果您只需要阅读或查找它，您可以创建一些专用服务来使用基础架构组件查找数据。您的MainClassService 似乎就是这种情况，您只需要阅读/查找一些RelatedItem 实体。

为了明确目的只是读取，MainClassService 需要返回RelatedItem 实体的只读表示。

所以，您刚刚迈出了迈向 CQRS 的第一步，其中模型分为两个：READ 模型和 WRITE 模型。