domain-driven-design - 存储库添加和创建方法

Question

为什么存储库的 .Add方法通常实现为接受要添加的实体实例，使用 .Id已经“设置”(尽管可以通过反射再次设置)，这应该是 repo 的责任吗？
将其实现为 .CreateAndAdd 不是更好吗？ ?
例如，给定 Person实体:

public class Person
{
    public Person(uint id, string name)
    {
        this.Id = id;
        this.Name = name;
    }

    public uint Id { get; }
    public string Name { get; }
}

为什么存储库通常实现为:

public interface IRpository<T>
{
    Task<T> AddAsync(T entity);
}

而不是:

public interface IPersonsRpository
{
    Task<Person> CreateAndAddAsync(string name);
}

Answer 1

这个问题已经有了很好的答案，我只想补充一些我的想法。 (它将包含与上一个答案的一些重复，所以如果这是一件坏事，请告诉我，我会删除它:))。

责任 ID 生成可以属于组织或系统的不同部分。

有时 ID 会由一些特殊规则生成，例如 Social Security Number .此号码可用作 的 ID人 在系统中，所以在创建 之前人 此代码必须从特定的 生成的实体SSN生成器服务。

我们可以使用随机生成的 ID，如 UUID。 UUID 可以在 之外生成。存储库并在创建期间分配给实体，存储库只会将其存储(添加，保存)到数据库中。

数据库生成的 ID 非常有趣。您可以拥有像 RDBMS 中的顺序 ID、像 MonogoDB 中的 UUID-ish 或一些哈希。在这种情况下，责任 ID 生成分配给数据库，因此它只能在实体存储后发生，而不是在创建时发生。 (我在这里允许自己自由，因为您可以在保存交易或阅读最后一个交易之前生成它等等。但我喜欢在这里概括并避免讨论具有竞争条件和冲突的案例)。这意味着您的实体在保存完成之前没有身份。这是一件好事吗？当然这取决于:)

这个问题是 leaky abstractions 的一个很好的例子.

当您实现解决方案时，有时使用的技术会影响它。您将不得不处理这样一个事实，例如 ID 是由您的数据库生成的，它是您的 的一部分。基础设施 (如果您在代码中定义了这样的层)。即使您使用 RDBMS，您也可以通过使用 s UUID 来避免这种情况，但是您必须在这些 ID 上加入(同样是技术特定的东西 :) )所以有时人们喜欢使用默认值。

而不是 添加 或 添加并创建 你可以有保存 方法而不是做同样的事情，这只是一些人喜欢的不同术语。存储库确实经常被定义为“内存中的集合”，但这并不意味着我们必须严格遵守它(大多数时候这样做可能是件好事，但仍然......)。

如前所述，如果您的数据库生成 ID，存储库似乎是分配 ID 的好人选(在存储之前或之后)，因为它是与数据库交谈的人。

如果您使用事件生成 ID 的方式可能会影响事物。例如，假设您想要 用户注册事件 将 UserID 作为 s 属性。如果您使用数据库生成 ID，则必须存储 用户 首先，然后创建和存储/调度事件或做一些事情。另一方面，如果您事先生成 ID，则可以将事件和实体一起保存(在事务中或在同一文档中无关紧要)。有时这会变得很棘手。

背景、对技术和框架的经验、对文学、学校和工作术语的接触会影响我们对事物的看法以及哪些术语对我们来说听起来更好。此外，我们(大部分时间)在团队中工作，这会影响我们如何命名事物以及如何实现它们。