在设计 ORM 时，表现关系的最佳方法是什么？答案

【问题标题】：While designing ORM, what is the best approach to represent relationship, performance-wise?在设计 ORM 时，表现关系的最佳方法是什么？
【发布时间】：2009-11-13 04:04:29
【问题描述】：

在设计 ORM 时，从性能角度来说，表示关系的最佳方法是什么？我的意思是，在以下两种方法中，哪种方法最能考虑性能？

class Employee
{
     int ID { get; set; }

     String Name { get; set; }

     int DepartmentID { get; set; } //This approach uses DepartmentID
}

--- 或 ---

class Employee
{
     int ID { get; set; }

     String Name { get; set; }

     Department Department { get; set; } //This approach uses Department class 
}

在我看来，第二种方法很好。它也是面向对象的。这应该是 ORM 的主要目的；将关系从 RDBMS 转换为面向对象。但是这样做，我们需要将整个部门对象加载到员工对象中，即使它不是必需的。

在您看来，您应该如何表示或最好的方法是什么？

【问题讨论】：

标签： design-patterns oop orm domain-driven-design

【解决方案1】：

大多数 ORM 框架将处理第二种情况，其性能与第一种情况相同。以 Hibernate 作为这里的参考示例，他们会毫不含糊地告诉你永远不要做第一个选项。实际上，他们对此有点刻薄。

事实上，我相信第一个选项在技术上不会被视为 ORM，因为关系是在 OOP 代码中的 ID 级别处理的。

Hibernate（像大多数其他人一样）具有延迟加载，这意味着您可以加载您的 Employee 并且它不会获取 Department。但是如果你说employee.getDepartment()，它会在那个时候执行简单的select语句来获取部门数据。

这也恰好可以在映射时或查询时进行配置，因此如果您有一些用例知道您需要 Department，您可以通过告诉它同时获取 Employee 和 Department 来保存第二个 SQL 调用加入查询。

查看 Hibernate 的 "Small Primer on Fetch Strategies" 了解更多信息。

【讨论】：

【解决方案2】：

您忘记了相关项目可以延迟加载。

也就是说，当您创建 Employee 对象时，您不必填充 Department 字段。可以在调用 get 访问器时填充它。

【讨论】：

【解决方案3】：

这在性能上并没有太大差异，实际上只是其中一个比另一个更容易实现。

【讨论】：