c# - 哪个类应该负责为实体创建 ID？

Question

我在解决以下问题时遇到了一些困难。假设我想管理项目中的依赖项，因此我的域不会依赖于任何外部内容 - 在存储库的这个问题中。在此示例中，假设我的域位于 project.Domain 中。

为此，我在 project.Domain 中声明了我的存储库的接口(interface)，并在 project.Infrastruct 中实现了该接口(interface)。阅读 Vernon 的 DDD 红皮书，我注意到他建议为聚合创建新 ID 的方法应放置在存储库中，如下所示:

public class EntityRepository
{
    public EntityId NextIdentity()
    {
        // create new instance of EntityId
    }
 }

在这个 EntityId 对象中将是 GUID，但我想显式地对我的 ID 进行建模，因此这就是我不使用普通 GUID 的原因。我也知道我可以完全跳过这个问题并在数据库端生成 GUID，但为了这个论点，我们假设我真的想在我的应用程序中生成它。

现在我只是在想 - 是否有任何具体原因将该方法放置在存储库中，如 Vernon 建议的那样，或者我可以在实体本身内部实现身份创建，例如

public class Entity
{
    public static EntityId NextIdentity()
    {
        // create new instance of EntityId
    }
 }

Answer 1

是的，您可以绕过对存储库的调用，只在实体上生成身份。然而，问题在于您已经破坏了存储库背后的核心思想:将与实体存储相关的所有内容与实体本身隔离。

我想说将 NextIdentity 方法保留在存储库中，并且仍然使用它，即使您只是生成 GUID 的客户端。这样做的好处是，在将来您想要更改身份的播种方式时，您可以通过存储库提供支持。然而，如果您直接在实体上采用该方法，那么您必须稍后进行重构才能支持此类更改。

此外，请考虑在测试等情况下使用不同存储库的情况。 IE。您可能想要生成具有相同 ID 的两个身份并执行冲突测试或“这是否正确失败”。让存储库处理生成使您有机会以这种方式发挥创意，而无需制作完全独特的测试用例，这些测试用例不会模仿实际的生产调用会发生的情况。

TLDR；即使您的标识符可以由客户端生成，也将其保留在存储库中。