DataContext の最適な使用パターン

Question

にとって最適な生涯モデルは何ですか DataContext?必要なときに新しいものを作成するだけでよいのか (関数レベル)、それを使用する各クラスで利用可能なものを保持しておくべきなのか (クラス レベル)、静的 DataContext を持つ静的クラスを作成する必要があるのか​​ (アプリドメイン)レベル）？これに関して考えられるベストプラクティスはありますか?

Answer 1

変更を保存する場合は、実行する操作の存続期間中、同じデータ コンテキストを利用できるようにしておく必要があります。 .SubmitChanges()そうしないと、それらの変更が失われます。

クエリを実行するだけの場合は、必要に応じて作成しても問題ありませんが、後で必要な場合は、 .SubmitChanges() コードを何度もリファクタリングする必要があるため、効果的に datacontext 最初からアプリ全体でグローバルに設定します。

データコンテキストが次のとおりであることに注意してください。 切断された. 。接続はクエリ データが存在する場合にのみ確立されます。 列挙された (最初にクエリを実行したときではなく、「遅延」データ型であるため、必要なときにのみデータを提供します)、その後すぐに閉じられます。の上 .SubmitChanges() 変更を送信するために接続が開かれ、その後すぐに閉じられます。だから、それを維持することは考えないでください datacontext around は接続を開いたままにしますが、そうではありません (フックすることができます) StateChange 接続のイベントを確認して自分で確認してください。そう確信しています)。

素晴らしい記事があります リック・シュトラールのブログ このトピックについては、ここでの私の回答よりもはるかに詳しく説明されています。

Answer 2

ジェフ・アトウッドがこのことについて次のように語っていたと思います。 ハーディングコードのポッドキャスト, 、まったく同じことについて質問されたとき。最後の15〜20分くらいを聞いてください。

SOでは、データコンテキストはControllerクラスで作成されると思います。ここでは多くの詳細についてはわかりません。しかし、それはそのように見えました。