JPA：沒有覆蓋實體中的equals（）和hashCode（）？

Question

閱讀本文之后 ，我總是彎向不重寫equals（）和hashCode（）。

在該文章的摘要中，關於所有列中的no eq / hC，唯一的結果是我無法進行比較操作，如：

1. 在分離實體的List中包含（），或
2. 比較來自不同會話的相同實體

並期望得到正確的結果。

但我仍然有疑問，並想問你的經驗，這是否是一個不好的做法，完全跳過equals和hashCode以及我現在還不知道的其他后果。

只是另一個信息點，我傾向於使用List Collections over Set。 我的假設是，當存儲在List中時，我真的不需要覆蓋hashCode並且相等。

Answer 1

是否完全跳過equals和hashCode是一種不好的做法

是。 你應該總是覆蓋你的equals和hashCode。 期。 原因是此方法已存在於您的類中，在Object中實現。 事實證明，這種實現是通用的，並且幾乎100％的時候它對您自己的對象來說是錯誤的實現。 因此，通過跳過equals / hashCode，您實際上提供了錯誤的實現，並且（在最好的情況下）會混淆使用這些類的人。 它可能是您的同事，也可能是您正在使用的某個框架（這可能導致不可預測且難以調試的問題）。

沒有理由不實施這些方法。 大多數IDE為equals / hashCode提供了一個生成器。 您只需要通知IDE有關您的業務密鑰。

Answer 2

你從那篇文章中得到了完全相反的結論。

Hibernate嚴重依賴於equals正確實現。 如果你不這樣做會發生故障。

事實上，幾乎所有事情都有; 包括標准的java集合。

使用持久性時，默認實現不起作用。 您應該始終實現equals和hashcode。 關於如何做到這一點也有一個簡單的規則：

• 對於實體，請使用對象的鍵。
• 對於值對象，請使用值

始終確保您在equals / hashcode中使用的值是不可變的。 如果你將它們傳遞出去（就像在吸氣劑中一樣），最好以不可變的形式傳遞它們。

這個建議會改善你的生活:)

Answer 3

閱讀這篇關於這個主題的非常好的文章： 不要讓Hibernate竊取你的身份 。

文章的結論是這樣的：

當對象持久化到數據庫時，對象標識很難正確實現。 但是，問題完全源於允許對象在保存之前沒有id存在。 我們可以通過從對象關系映射框架（如Hibernate）中分配對象ID來解決這些問題。 相反，只要實例化對象，就可以分配對象ID。 這使對象標識簡單且無錯誤，並減少了域模型中所需的代碼量。