ビジネスレイヤーが新しいエンティティを作成するとき、これは更新する必要がある既存のエンティティのインスタンスを論理的に表します（たとえば、同じビジネスキーを共有しているとします）、この方法は悪い習慣をマージするのですか？
public User add(User user){
User existingUser = getUserDao().findByBusinessKey(user.getBusinessKey(), false);
user.setId(existingUser.getId());
user = getUserDao().merge(user);
return user;
}
分離されたエンティティにIDを明示的に設定するのは奇妙に感じるので、私は尋ねますが、Userエンティティのequalsおよびhashcodeメソッドが適切に実装されている場合でも、ここでIDを設定することが、マージを確実に行う唯一の方法です。
もっと良い方法はありますか？
この方法には後で私を悩ませる特定の欠点はありますか？
ご覧いただきありがとうございます！
そのコードは機能しますが、分離されたエンティティにIDを明示的に設定する必要はありません。典型的なHibernateアプリには、2つのケースを処理する「保存」メソッドがあります。
コード内の何かが2番目のケースを通常の方法で実行していないようです。'user'オブジェクトが以前のHibernateクエリからのものである場合（ユーザーが[edit user]をクリックするなどによってトリガーされた場合）、オブジェクトにはすでにIDがあります。したがって、merge(user)呼び出しのみが必要です。
私は通常次のようなことをします：
if (user.getId() == null)
em.persist(user);
else
user = em.merge(user);
次に、楽観的ロックの問題（別のセッションでオブジェクトが更新された）と一意の制約の問題（別のセッションで同じビジネスキーで何かを永続化しようとした）を処理するコードを追加します。
Seamなどのフレームワークは、コントローラーBeanメソッド間でHibernateセッションを伝播するため、これをさらに簡単にすることができます。したがって、「マージ」も必要ありません。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加