linq-to-sql - DataContextの最適な使用パターン

Question

の最良の寿命モデルは何DataContextですか？必要なときにいつでも新しいものを作成する必要がありますか（別名、関数レベル）、それを使用する各クラスで使用できるようにしておく必要がありますか（クラスレベル）、静的なDataContextを使用して静的なクラスを作成する必要があります（app-domainレベル）？これに関して考慮されているベストプラクティスはありますか？

Answer 1

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

何かを照会するだけの場合は、必要に応じてそれらを作成しても問題ありませんが、後で必要に応じ.SubmitChanges()てコードを大幅にリファクタリングする必要があるためdatacontext、アプリ全体でグローバルを効果的に維持するパターンを採用することもできます。最初から。

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

Rick Strahl's Blogには、このトピックについて詳しく説明している素晴らしい記事があり、ここでの私の回答よりもはるかに多くの情報が提供されています!!

Answer 2

ジェフ・アトウッドは、まったく同じことについて質問されたとき、ハーディング・コードのポッドキャストでこれについて話したと思います. 最後の 15 ～ 20 分程度で聞いてください。

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