11
假設我們要構建一個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