hibernate - 什么时候适合使用双向关联，什么时候不适合？

Question

让我们假设我们想要构建一个类似 eBay 的应用程序，其中我们有一个名为 Customer 的实体。和一个名为 Order 的实体.

从关系的角度来看，我将其建模为:

Customer
+----+-----+
| ID | ... |
+----+-----+

Order
+----+-------------+-----+
| ID | CUSTOMER_ID | ... |
+----+-------------+-----+

现在，当我想将其映射到 JPA 时，我有多种选择:

创建从订单到客户的单向多对一关联。恕我直言，这是最接近关系模型的。缺点是为了找到给定客户的所有订单，我必须编写一个 JPQL 查询，因为客户对其订单一无所知。此外，我不能以面向对象的自然方式为客户添加新订单(例如 customer.addOrder(aNewOrder); )。

创建从客户到订单的一对多关联。这样为了找到给定客户的所有订单，我可以使用 customer.getOders()我可以以面向对象的自然方式为客户添加新订单。缺点是为了找出下达给定订单的客户，我应该使用 JPQL。

创建从客户到订单的双向一对多关联。这样我就不需要编写任何 JPQL 查询来检索客户或已下给定订单的客户的所有订单。缺点是增加了维护双向关联的复杂性。

因此，对于是否必须使用单向关联或双向关联是否“正确”，我没有看到明确的论据。换句话说，在我看来，这一切都归结为模型设计者/实现者的个人喜好和品味。

我是对的还是有规则可以确定给定关联的正确方向？

Answer 1

在很大程度上取决于您对每位客户的预期订单数量。如果您期望每个客户有很多订单(想想 eBay)，那么让客户拥有与其关联的所有订单将不会非常有效(或者需要花费一些精力来维持懒惰的关联)。在这种情况下，我推荐方法#1。写一些查询没有错。

但是，如果您预计大多数客户的订单很少，那么双向方法 #3 就可以正常工作。

我认为 #2 没有太大值(value)，因为订单总是与一位客户相关联。