4.2 JPA的 hashCode（）/ equals（）困境｜ Java Debug 笔记

本文正在参加「Java主题月 – Java Debug笔记活动」，详情查看<活动链接>

提问：关于JPA的 hashCode（）/ equals（）困境

这里已经讨论了一些 有关JPA实体以及JPA实体类应使用 hashCode()/ equals()哪种进行实现的讨论。
它们中的大多数都依赖于Hibernate，但是我想讨论它们如何自我实现（顺便说一下，我正在使用EclipseLink）。

在以下方面，所有可能的实现都有各自的优点和缺点：

1， hashCode()/ equals()对List以及Set的操作的不变性。

2， 可以检测到相同的对象（例如，来自不同的会话，来自延迟加载的数据结构的动态代理）

3， 实体在从【相对于主从的主来说】（或非持久）状态下是否行为正确

在我看来，有三种操作：

不要覆盖它们；依靠Object.equals()和Object.hashCode()

• hashCode()/equals()工作
• 无法识别相同的对象，动态代理问题
• 独立实体没有问题

根据主键覆盖它们

• hashCode()/equals()无法正常使用
• 正确的识别出来（对于所有管理实体）
• 独立实体的问题

根据Business-Id（非主键字段；外键如何？） 覆盖它们

• hashCode()/equals()坏了
• 正确的身份（对于所有管理实体）
• 独立实体没有问题

我的问题是：
我有遗漏什么吗？

回答1：

阅读有关该主题的一篇非常不错的文章：不要让休眠模式窃取您的身份。

本文的结论是这样的：

当将对象持久化到数据库时，很难正确实现对象标识。但是，问题完全出在允许对象在保存之前不带id的情况下存在。我们可以通过从对象关系映射框架（例如Hibernate）中分配对象ID来解决这些问题。我们可以在实例化对象后立即分配对象ID。这使对象标识变得简单且无错误，并减少了域模型中所需的代码量。