プラットフォームを指定していないため、この質問に完全に答えるのは難しいので、「切断された」とはどういう意味か正確にはわかりません。Hibernateの「切断」とは、有効なセッションにオブジェクトがありますが、データベース接続が現在開いていないことを意味します。それは些細なことです。単に再接続して遅延ロードするだけです。より複雑な状況は、「切り離された」オブジェクトがある場合、つまりアクティブなセッションにまったく関連付けられていない場合です。その場合、単に再接続することはできません。新しいオブジェクトを取得するか、必要なオブジェクトをにアタッチする必要があります。アクティブなセッション。
いずれにせよ、より複雑なシナリオでも、要件が非常に柔軟性がないため、遅延読み込み戦略にはそれほど多くはありません。遅延かどうかにかかわらず、何かを読み込むには「接続」する必要があります。限目。「切断された」とは、切断されたものと同じことを意味すると思います。戦略は2つの基本的なシナリオになります。これは、遅延ロードにオンザフライで再接続/接続する必要がある状況か、切断する前に条件付きで追加のオブジェクトをロードすることを決定したいシナリオです。そもそも？
実際には、両方の可能性についてコーディングする必要がある場合があります。
あなたの場合、古いパスワードを遅延ロードするだけでなく、最初にUserオブジェクトを更新するためにも接続する必要があります。また、これはASP.NETであるため、要求ごとにセッションを使用している可能性があります。その場合、オプションは基本的に1つになります。切断前の条件付き遅延ロードで、それだけです。
最も一般的なシナリオは、ユーザーがログインし、システムがパスワードを変更する必要があると判断し、続行する前に変更するように要求することです。その場合は、ログイン後すぐに処理して、ユーザーの接続を維持することをお勧めします。ただし、おそらくリクエストごとにセッションを使用しているため、最初のリクエストプロセスで制限時間を設定し、期限が切れてもここに接続しているので、完全にロードされたユーザーを返します（履歴を使用していると仮定します）。ある種のクライアント側スクリプト検証のパスワード）。次に、送信トリップで、再接続するか、新しいUserインスタンスを取得して更新します。
そうすれば、いつでもパスワードを変更するオプションを提供しなければならない可能性が常にあります。それらはすでにログインしています。ここではそれほど重要ではありません。ユーザーがいますが、リクエストはかなり前に終了し、パスワードはロードされていません。ここでは、おそらく、パスワード変更関数を呼び出すときに、サービスが更新目的でのみ完全な履歴を持つUserオブジェクトの2番目のコピーを取得し、パスワードを更新して、そのオブジェクトを破棄するサービスメソッドを作成します。セッションまたは認証の目的で使用します。または、リクエストごとにセッションを使用している場合は、同等のことを行う必要があります。クライアント側の検証のために、完全に初期化されたオブジェクトを取得します。
認証されたセッションの開始後にパスワードが必要な場合でも、同じことを実行して、ローカルユーザーを置き換えるか、ローカルユーザーのメモリ内のパスワードバージョンを更新することもできます。
複数のレベルの認証で多くのことが行われている場合は、パスワードを変更した後、ログオフして完全にログインし直す必要がある可能性が高いため、一度ユーザーの状態はそれほど重要ではありません。パスワードの変更を要求します。
いずれの場合も、リクエストごとにセッションを使用していて、リクエストごとにオブジェクトが完全に切り離された場合、最初のシナリオでは、元のリクエストでサーバー上にいるときに、クライアント側の検証のためにデータを返すために遅延読み込みを行うことができます。2番目のシナリオでは、別の旅行を行う必要があります（ここでは、遅延読み込みなどは実際にはありません）。どちらの場合も、更新前は常に切断されているため、2つの更新オプションを比較検討する必要があります。送信トリップでデータベースから2番目のインスタンスを取得して更新するか、既存のインスタンスを再接続することができます。それは何が最適/最も簡単かによって異なります-珍しいイベントのためにdbラウンドトリップを保存することは本当に重要ですか？選択したORMを使用して再接続すると、とにかくデータベースに再びヒットする可能性がありますか？おそらく、再接続する必要はなく、必要に応じて実際の更新用の新しいインスタンスを取得するだけです。