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

假设我们要构建一个eBay应用程序，其中我们有一个名为Customer的实体和一个名为Order的实体。什么时候适合使用双向关联，什么时候不适用？

从关系的角度来看，我会为模型这样的：

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

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

现在，当我要地图这JPA，我有多种选择：

建立单向多从订单到客户的一对一关联。恕我直言，这是最接近关系模型。缺点是，为了找到给定客户的所有订单，我必须编写JPQL查询，因为客户不知道其订单。另外，我无法以自然的OO方式为客户添加新订单（例如customer.addOrder(aNewOrder);）。
创建从客户到订单的一对多关联。通过这种方式，为了找到给定客户的所有订单，我可以使用customer.getOders()，我可以以OO自然方式为客户添加新订单。缺点是为了找到已经下达给定订单的客户，我应该使用JPQL。
从客户到订单创建双向一对多关联。这样我就不需要编写任何JPQL查询来检索给定订单的客户或客户的所有订单。缺点是增加了维护双向关联的复杂性。

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

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

显然，当您需要从双方访问时，使用双向关系。持久性解决方案根本不应该选择这种选择。 – DataNucleus 2011-06-13 07:20:55

@DataNucleus：但最终有可能找到已经下达给定订单的客户或客户的订单，无论该关联是否是双向的。 – 2011-06-13 07:37:57

当然，但我的观点是你设计你的模型以适应它在应用程序中的使用方式，而不是容纳持久层。是的，总是有可能为客户或客户订购订单，而不管是否出价 - 您选择基于表现等获取该信息的机制。 – DataNucleus 2011-06-13 07:56:58

很大程度上取决于您预期的每位客户的订单数量。如果你期望每个客户有很多订单（想想eBay），那么让客户处理与其相关的所有订单将不会非常有效（或者需要一些努力来保持懒惰关联）。在这种情况下，我建议方法＃1。写一些查询没有错。

但是，如果您期望大部分订单很少的客户，那么双向方法＃3就可以正常工作。

因为订单总是与一个客户关联，所以我没有在＃2中看到很多价值。

2011-06-13 07:06:05

回答