JPA hashCode（）/ equals（）のジレンマ
JPAエンティティーと、JPAエンティティークラスにどの/ 実装を使用する必要があるか について、ここでいくつかの議論がありました。それらのほとんど（すべてではない）がHibernateに依存していますが、JPA-implementation-neutrally（ちなみに私はEclipseLinkを使用しています）について説明したいと思います。hashCode()equals() 考えられるすべての実装には、以下に関する独自の長所と短所があります。 hashCode()/equals()契約準拠のため（不変性）List/ Setオペレーション 同一のオブジェクト（たとえば、異なるセッションから、遅延ロードされたデータ構造からの動的プロキシ）を検出できるかどうか エンティティがデタッチ（または非永続）状態で正しく動作するかどうか 私が見る限り、3つのオプションがあります。 それらを上書きしないでください。頼りにしObject.equals()てObject.hashCode() hashCode()/ equals()仕事 同一のオブジェクトを識別できない、動的プロキシの問題 エンティティの分離に問題はありません 主キーに基づいてそれらを上書きする hashCode()/ equals()壊れている 正しいID（すべての管理対象エンティティ） 分離されたエンティティに関する問題 Business-Idに基づいてそれらをオーバーライドします（非主キーフィールド。外部キーはどうですか？） hashCode()/ equals()壊れている 正しいID（すべての管理対象エンティティ） エンティティの分離に問題はありません 私の質問は： オプションやプロ/コンポイントを逃しましたか？ どのオプションを選択しましたか、またその理由は何ですか？ 更新1： 「によってhashCode()/ equals()壊れている」、私はその連続した意味hashCode()（正しく実装時）の意味で壊れされていない、異なる値を返す可能性があります呼び出しをObjectAPIドキュメント、しかしから変更されたエンティティを取得しようとしたときにこれは問題を引き起こすMap、 Setまたは他のハッシュベースCollection。その結果、JPA実装（少なくともEclipseLink）が正しく動作しない場合があります。 更新2： あなたの答えをありがとう-それらのほとんどは驚くべき品質を持っています。 残念ながら、どのアプローチが実際のアプリケーションに最適か、または自分のアプリケーションに最適なアプローチをどのように決定するかはまだわかりません。だから、私は質問を開いたままにし、いくつかの議論や意見を期待します。