3

背景:次のクラスの永続性を実装しています。

  • class Person

  • abstract class ContactInfo

    • Email extends ContactInfo
    • SnailMail extends ContactInfo

PersonはContactInfoオブジェクトへの参照を持っています。(また、ContactInfoオブジェクトは複数のPerson間で共有できます。)

私のユーザー インターフェイスでは、ユーザーが連絡先情報オブジェクトを編集できるようにする必要があります。(置き換えられる連絡先情報オブジェクトが複数のユーザーで共有されている場合は、それらすべてのユーザーの連絡先情報が更新されている必要があります。)

しかし、私が理解しているように、Hibernate は識別子列の更新を拒否するため、単純に新しいSnailMailオブジェクトを作成し、置き換えるEmailオブジェクトの主キー値を与えて保存しても機能しません。

質問:ユーザーがContactInfoオブジェクトをEmailからSnailMailに変更できるようにする最善の方法は何ですか?

(オブジェクトは「短命」です。これは Web アプリの一部であり、すべてのオブジェクトは要求ごとに HQL を介して再読み取りされるため、心配する切り離されたオブジェクトは実際にはありません。)

これまでの私の考え:古いオブジェクトを削除して、新しいオブジェクトを挿入できることに気付きました。これが好ましいアプローチである場合、(A) 古い主キー値を再利用するか (この場合、割り当てられたジェネレーターを使用する必要があります)、または (B) バックエンドに新しいオブジェクトの新しい ID を生成させます。個人の連絡先参照を更新して、新しいオブジェクトを指すようにしますか?

(B) が進むべき道である場合、HQL ステートメントを使用して参照の更新を行うことができますか、または影響を受けるすべての人物オブジェクトを「手動で」ロード/更新/保存する必要がありますか?

4

1 に答える 1

0

別のクラスのまったく新しいインスタンスで更新できる可能性は低いと思います。結局のところ、新しいエンティティを作成したので、実際には更新ではありません。

Person が複数の ContactInfo(s) を必要としないことは確かですか? リレーションが多対多の場合は、そのように管理できます。おそらく、すでに同様のケースを管理している可能性があります。Web インターフェイスは、「アドレス 1、2、...」を明示的に表示し、それぞれが特定のタイプに基づいてレンダリングされ、最後に「-」ボタンと「+」ボタンが付いています。これにより、タイプを変更したい場合は連絡先情報を削除/追加する必要があることが明確になります。

同様のアプローチは、ユーザーがそのタイプを変更した場合にのみ、連絡先情報を削除/再作成することです (おそらく、新しい Web フォームを既にレンダリングする必要があります)。このような場合、他の人物へのリンクを更新することは避けられないと思います。私は関係を双方向にすることでそれを行います。つまり、Person.getContactInfo() と ContactInfo.getPersons() の両方を導入します。add()/delete() メソッド内で双方向性を管理します (つまり、addContactInfo( ContactInfo c) は c.addPerson ( this ) を呼び出す必要があり、その逆も同様です。こちらを参照)。Hibernateは外部キーを自動的に更新できる必要があります。 .

于 2013-10-29T11:04:57.273 に答える