4

素敵なイコールとハッシュコード、すべての理論はここにあり、ここにもあります

多くの休止状態のエンティティ/ドメイン オブジェクトで、equals() および hashcode() 内で自動生成された ID を使用することにしました。

ただし、多くの Web サイトでは、比較中またはハッシュコードの使用中にオブジェクトを初めてデータベースに永続化するリスクがあるため、これを行うべきではないと述べています。

私の見解では、ほとんどのユースケースで、これが変更される可能性は他のどのフィールドよりもはるかに低いということです。

個々のドメイン オブジェクトには、最初に作成されたときに id が生成されますが、他のほぼすべてのフィールドは、通常のビジネス プロセス中に変更される可能性があります (一意のユーザー名でさえも変更できます ... )。

そして、私のドメイン オブジェクトの多くでは、一意の ID が考慮すべき唯一の適切なフィールドです (人、住所、ペット、... 顧客など)。フィールドを組み合わせるのは良い考えですが、自動生成された ID を使用しないのは良いアドバイスではないと思います。

他に何か不足していますか？

4

3 に答える 3

5

Hibernate Community Wiki のEquals と HashCodeを読む必要があります。

でデータベース識別子を使用しない主な理由はequals、暗黙のうちに、hashCode格納されているが永続化されていないエンティティを処理するためです。equal永続化する前に、そのケースを明示的に処理するように注意しない限り、すべてのインスタンスは になります。

このシナリオに陥らないことがわかっていて、十分に文書化されていることを確認している場合は、問題ない可能性があります。後でいつでも実装を変更できます。

于 2011-09-28T07:35:46.567 に答える
0

新しいユーザー入力に基づいて作成されたオブジェクトを Set に入れたため、auto-id-generation で equals 問題に遭遇しました。したがって、明示的にそれらを比較したり、何かを比較したりしませんでした。それらをセットに入れただけです。Set は equals()/hashCode() に依存しているため、その時点ですでに失敗していました (他にオプションがなかったため、これもオブジェクト ID に基づいていました)。

次に、実際にIDを自分で生成して割り当てるように変更しました。これははるかに優れたソリューションでした。

この記事を読んでください。問題を正確に説明しています: dont-let-hibernate-steal-your-identity

于 2011-09-28T07:33:49.147 に答える