域实体中的外键属性答案

【问题标题】：Foreign key properties in domain entities域实体中的外键属性
【发布时间】：2013-12-30 12:45:14
【问题描述】：

在域驱动设计中，域模型应该完全不知道任何数据持久性细节。

假设Employee 属于Department。域实体可能如下所示：

public Employee
{
    public string EmployeeId { get; set; }
    public string FirstName { get; set; }
    public string LastName{ get; set; }
    public Department Department { get; set; }
    public int DepartmentId { get; set; }
}

public Department
{
    public string DepartmentId { get; set; }
    public string Name{ get; set; }
}

Employee.DepartmentId 是否真的与域模型相关，还是基础架构存储细节？

Employee.Department 肯定是这个级别的关系吗？

在我的例子中，这些实体将存储在 SQL 数据库中，数据将由 Entity Framework 检索，因此数据库中将存在 Employee.DepartmentId 列。

【问题讨论】：

这里的问题是您正在重新使用主键（数据库概念）作为域模型中的对象标识。实体应具有在模型中定义的自然/代理身份 - 例如，这可能是一个指南。这将用于查询存储库。数据库行 id 只是持久化平台的一个实现细节。

标签： c# entity-framework domain-driven-design repository-pattern poco

【解决方案1】：

如果您使用外键，实体框架中的生活会更轻松：

Why does Entity Framework Reinsert Existing Objects into My Database?

Making Do with Absent Foreign Keys

而且你说外键与域模型并不真正相关是绝对正确的。它是持久性模型的一部分。

所以你需要决定加入哪个阵营。你是纯粹主义者还是实用主义者？是否分离域模型和持久性模型？

ORM Entities vs. Domain Entities under Entity Framework 6.0

【讨论】：

为什么与领域模型“不相关”？我可以理解为什么 FK 特别不合适，因为它是一个持久性问题。但在现实世界中，员工与部门之间肯定存在关系。 DDD 的一个关键原则是在模型中准确地反映领域。所以我希望在模型中看到一些东西来代表这种关系。 FK 不是关系的衍生产物吗？
抱歉，我设法错过了代码中的“部门”属性。如果没有这个，我会错过如何在缺少 FK 的情况下对 rel 进行建模。现在说得通了，抱歉打扰了。
是否更容易有点主观。在某些情况下，某些方面更容易，而其他方面则更难。如今，附加现有实体的需求往往属于少数情况，其中 Web 应用程序占 .Net 开发的最大份额。使用 LoadEntity() 扩展方法可以缓解 99% 的情况，并允许使用更清晰、因此更易于维护的域模型。