最近Linq2SQLを使用してASP.Netアプリケーションを継承しました。現在、すべてのページで静的と宣言されているDataContextオブジェクトがあり、それらがnull（シングルトン、並べ替え）であることがわかったときに作成します。DataContext静的変数の使用
これが良いか悪いかは、コメントが必要です。私がDBから、そして私が同様に書く必要がある状況で読む必要がある状況では。
アプリケーション全体で1つのDataContextインスタンスを持つのはどうでしょうか？
アプリケーションごとに1つのDataContextがうまく実行できませんでした。私は恐れています。 DataContextはスレッドセーフではないため、ページの静的メンバーとして使用する場合でも、悪い考えです。 asgerhallasが言及したように、作業単位（通常は単一の要求）のコンテキストを使用することが理想的です。それ以外の場合は、すべてのデータがメモリに格納されていることがわかり始めます。明示的なリフレッシュなしに更新が表示されることはありません。それらの2つのテーマに話し合ういくつかの投稿があります：Identity MapsとUnits of Work
リクエストごとに1つのDataContextを使用しますが、直面しているシナリオによって異なります。 L2Sのポイントは、作業パターンの単位でそれを使用することだったと思います。しかし、大規模なアプリケーションではうまく機能しません。後でエンティティを新しいコンテキストに再接続するのはかなり難しいからです。
リックシュトラールは、ここで話題に本当の良い導入を持っている：私は、私が過去にに問題があったと言うことができ
http://www.west-wind.com/weblog/posts/246222.aspx
ことの一つは、読み取りと書き込みの両方のシナリオにあるコンテキストを持つことです。 datacontextで行われた変更の追跡は、あなたが読んでいるときにはかなりのオーバーヘッドです。ほとんどのWebアプリケーションがほとんどの場合そうしているのです。 datacontextを読み込み専用にすることができますし、かなり速度が上がりますが、書き込みのために別のコンテキストが必要になります。