java - JPA hashCode()/equals() 困境

Question

有some discussions这里是关于 JPA 实体和其中 hashCode()/equals()实现应该用于 JPA 实体类。它们中的大多数(如果不是全部)都依赖于 Hibernate，但我想讨论它们 JPA-implementation-neutrally(顺便说一下，我正在使用 EclipseLink)。

所有可能的实现都有自己的优点和缺点:

• hashCode()/equals() 为 List 签订契约(Contract) 符合性(不变性)/Set运营
• 是否可以检测到相同对象(例如来自不同 session 、来自延迟加载的数据结构的动态代理)
• 实体在分离(或非持久化)状态下的行为是否正确
  

据我所知，有三个选项:

1. 不要覆盖它们；依靠Object.equals()和 Object.hashCode()
   • hashCode()/equals()工作
   • 无法识别相同的对象，动态代理存在问题
   • 分离实体没有问题
2. 根据主键覆盖它们
   • hashCode()/equals()坏了
   • 正确的身份(适用于所有托管实体)
   • 分离实体的问题
3. 根据 Business-Id(非主键字段；外键呢？)覆盖它们
   • hashCode()/equals()坏了
   • 正确的身份(适用于所有托管实体)
   • 分离实体没有问题

我的问题是:

1. 我是否错过了一个选项和/或赞成/反对点？
   
2. 您选择了哪个选项，为什么选择？

更新 1:

“hashCode()/equals() 已损坏”，我的意思是连续的 hashCode()调用可能会返回不同的值，这在 Object 的意义上(正确实现时)不会被破坏。 API 文档，但在尝试从 Map 检索更改的实体时会导致问题, Set或其他基于散列的 Collection .因此，JPA 实现(至少是 EclipseLink)在某些情况下将无法正常工作。

更新 2:

感谢您的回答——他们中的大多数都具有非凡的品质。
不幸的是，我仍然不确定哪种方法最适合实际应用程序，或者如何确定最适合我的应用程序的方法。所以，我会保持这个问题的开放性，并希望有更多的讨论和/或意见。

Answer 1

阅读这篇非常好的文章:Don't Let Hibernate Steal Your Identity .

文章的结论是这样的:

Object identity is deceptively hard to implement correctly when objects are persisted to a database. However, the problems stem entirely from allowing objects to exist without an id before they are saved. We can solve these problems by taking the responsibility of assigning object IDs away from object-relational mapping frameworks such as Hibernate. Instead, object IDs can be assigned as soon as the object is instantiated. This makes object identity simple and error-free, and reduces the amount of code needed in the domain model.