HttpContext のような明確な束縛を利用できないため、デスクトップ アプリケーションでセッションを管理するのははるかに難しいと思います。では、アプリケーション全体に対して 1 つのセッションを開かずに、遅延読み込みを利用してセッションの有効期間を管理するにはどうすればよいでしょうか?
4 に答える
Ayende は最近、MSDN でこのテーマに関する優れた記事を書きました。
それはあなたのオブジェクトのデザインに帰着すると思います。遅延読み込みはオブジェクトごとのレベルで適用できるため、セッション管理について考えるときにその事実を利用できます。
たとえば、データが豊富で遅延ロードされるオブジェクトがたくさんあり、それらのグリッド/概要ビューと詳細ビューがあります。グリッド サマリー ビューでは、オブジェクトの遅延読み込みバージョンは使用しません。サロゲート オブジェクトを使用してそのデータを表示しますが、そのサロゲート オブジェクトは遅延ロードされません。
一方、ユーザーが表示/編集のためにそのレコードを選択し、オブジェクトの複数ページの詳細ビューに入ると、特定のオブジェクトに遅延読み込みが適用されます。オンデマンドでのみ表示される詳細に応じて、データが遅延ロードされるようになりました。そうすれば、遅延読み込み用に開いているセッションの範囲は、詳細ビューが使用されている間だけ持続します。
先ほどおっしゃったように、HttpRequest の境界を使用することはできませんが、デスクトップ アプリケーションにおける「HttpRequest」とは何かを理解することができます。
説明させてください。通常、HttpRequest はアクションのコントローラーになり、セッションをその特定のアクションに制限します。デスクトップアプリケーションでは、「コントローラー」(イベント) を小さくすることができますが、@Jon が言ったように、ウィンドウは簡単に境界を表すことができます。
コマンドパターンの設定を考えることができるかもしれません。各重要なイベントは、コマンドをフィードしてトリガーし、それを実行します。ベースの AbstractCommand.Execute() 実装は、セッションの初期化、トランザクションのラップ、具体的な SomeCommand._Execute() 実装の呼び出し、およびすべてのもののクローズを担当します。
とにかく、これは永続性にとらわれないというわけではありません。オブジェクトをロードし、プレーンなインスタンスだけを (したい) 処理する必要があるためです (特に、ここでは遅延ロードについて言及しています)。
そうでなければ、ある種の自動オープン/自動クローズ動作を実装することは可能ですか? これは、遅延読み込みトリガーなどの暗黙のケースであっても、上位レイヤーによるクエリのニーズに永続レイヤーを敏感にすることによって達成する必要があります。接続を閉じることに関しては、DB の非アクティブ状態が一定のタイムアウト (10 秒?) を超えると、永続化レイヤーが閉じる可能性があります。私は知っています、これは鋭くないです。しかし、実際には、上位層の永続性にとらわれなくなります。
ありがとう、マルチェロ