存储库模式：如何延迟加载？ 或者，我应该拆分这个聚合吗？

Question

我有一个具有编辑器和项目概念的域模型。

一个编辑者拥有多个项目，一个项目不仅有一个编辑者所有者，还拥有多个编辑者成员。 因此，一个编辑器也有多个“加入”的项目。

我采用 DDD 方法对此进行建模，并使用存储库模式进行持久化。 然而，我还没有充分理解这个模式，无法确定应该如何做到这一点。

我正在假设编辑器和项目可能位于同一聚合中，根是编辑器。 因此，我可以获得一个编辑器，然后枚举其项目，并可以从那里枚举项目的成员编辑器。

但是，如果我只允许从我的存储库中检索编辑器，这是否意味着当我获得拥有它们的编辑器时，我必须从存储库中加载所有项目？ 如果我想延迟加载成员编辑器，项目还需要对存储库的引用吗？

或者，如果我拆分聚合并拥有编辑器存储库和项目存储库，我应该如何处理两者之间的事务，例如将新项目添加到编辑器时？ 例如：

Editor e = new Editor("Editor Name");
editorRepository.Add(e);

Project p = e.CreateProject("Project Name");
projectRepository.Add(p);    // These two lines
editorRepository.Save(e);    // should be atomic

我是否误解了存储库模式的意图？

Answer 1

我是否误解了存储库模式的意图？

我会说“是的”，但要知道我和我共事过的每个人都出于同样的原因问过同样的事情......“你不是在第四维度思考，马蒂”。< /em>

让我们稍微简化一下，首先使用构造函数而不是 Create 方法：

Editor e = new Editor("Editor Name");
e = editorRepository.Add(e);

Project p = new Project("Project Name", e);
p = projectRepository.Add(p);

在下面，您的项目存储库始终在创建时将有效所有者 (p.EditorId) 存储到项目数据中，并且无论您如何重新填充编辑器的项目，它都会在那里。 这就是为什么将所有必需的属性放入构造函数中是一个好习惯。 如果您不想传递整个对象，则只需 e.Id 即可。

如果我想延迟加载成员编辑器，项目还需要对存储库的引用？

现在，至于如何根据需要重新填充编辑器的项目，您有几种选择，具体取决于您的目的。 Straight Repository 说你想要：

IEnumerable<Project> list = projectRepository.GetAllProjects()
                                .Where(x => x.editorId == e.Id);

但是把它放在哪里呢？ 不在项目或编辑器内部，你是对的，否则他们将必须访问存储库，这是不好的。 上面的代码片段是松散耦合的，但不能单独重用。 您刚刚达到了存储库模式的极限。

接下来是您的应用程序的适配器层，具有共享的存储库源 (StaticServiceWrapper) 和某种 EditorAdapter 对象（或聚合或任何您所说的名称），或者现在您可以混合使用可以流畅地与任何和所有必要的存储库通信的扩展方法。 我还没有在生产系统中完全按照这种方式完成，但向您展示一个简洁的示例：

public static class Aggregators
{
    // one to one, easy
    public static Editor GetOwner(this Project p)
    {
        return StaticServiceWrapper.editorRep.GetEditorById(p.editorId);
    }

    // one to many, medium
    public static IEnumerable<Project> GetProjects(this Editor e) 
    { 
        return StaticServiceWrapper.projectRep.GetAllProjects()
                .Where(x => x.editorId == e.Id);
    }

    // many to many, harder
    public static IEnumerable<Editor> GetMembers(this Project p)
    {
        var list = StaticServiceWrapper.projectMemberMap.GetAllMemberMaps()
                        .Where(x => x.projectId == p.projectId);

        foreach ( var item in list )
            yield return StaticServiceWrapper.editorRep.GetEditorById(item.editorId);
    }
}

基本上，一旦您的 GetAll、GetById、Add、Update、Remove 对象存储库完成，您就必须保留关联，并且继续沿着对象/层层次结构向上移动到适配器、缓存和业务逻辑等有趣的部分（“哦，天哪！”）。

Answer 2

将职责划分为 EditorOwner 和 EditorMember 怎么样？

在不知道您的域的情况下，我想他们会有不同的职责 - 例如，EditorOwner 可能非常富有（并且可能是聚合根），但项目可能只需要了解其成员的有限数量，所以EditorMember 对象可能非常轻。

这些域对象也可能与用户相关，但那将是在另一个上下文中。

这对事情有帮助吗，还是只会让事情变得更复杂？

Answer 3

这取决于您的应用程序的需求。 如果加载给定编辑器的所有项目是一个大问题，请尝试延迟加载模式，例如 虚拟代理。

关于延迟加载项目的成员编辑，如果您使用虚拟代理，我不会发现使用 EditorRepository 注入代理有问题，因为我不认为代理是域的一部分。

如果您拆分聚合，则可以研究工作单元模式作为原子性的一种解决方案。 不过，这个问题并不是 DDD 所独有的，我确信还有其他针对事务行为的解决方案。

Answer 4

这里有两种不同的关系，一种是所有权关系，一种是成员关系。

所有权关系是简单的一对多（每个项目一个所有者）。 成员关系是多对多的（项目有多个编辑，编辑有多个项目）。

您可以在 Project 类上提供 Owner 属性，并在 ProjectRepository 上提供一个方法来获取特定编辑器拥有的所有项目。

对于多个关系，在 Project 类上提供 Members 属性，并在 ProjectRepository 上提供一个方法来获取包含指定 Editor 作为成员的所有项目。

编辑和项目似乎也是实体，我可能会拆分聚合，但也许这些术语在您的上下文中具有特定的含义，使其成为聚合的子实体。