最近、Linq2SQL を使用して ASP.Net アプリを継承しました。現在、すべてのページで DataContext オブジェクトが static として宣言されており、null (シングルトン、一種) であることが初めてわかったときに作成します。
これが良いか悪いかコメントが必要です。DBから読み取るだけでよい場合と、書き込む必要がある場合があります。
アプリケーション全体で DataContext インスタンスを 1 つだけ持つのはどうですか?
最近、Linq2SQL を使用して ASP.Net アプリを継承しました。現在、すべてのページで DataContext オブジェクトが static として宣言されており、null (シングルトン、一種) であることが初めてわかったときに作成します。
これが良いか悪いかコメントが必要です。DBから読み取るだけでよい場合と、書き込む必要がある場合があります。
アプリケーション全体で DataContext インスタンスを 1 つだけ持つのはどうですか?
アプリケーションごとに1つのDataContextのパフォーマンスが低下するのではないかと思います。初心者にとって、DataContextはスレッドセーフではないため、ページの静的メンバーとして使用することもお勧めできません。asgerhallasが述べたように、作業単位(通常は単一の要求)のコンテキストを使用することが理想的です。それ以外の場合は、すべてのデータがメモリ内にあることがわかり、明示的に更新しないと更新が表示されません。これらの2つの主題について話しているいくつかの投稿があります:アイデンティティマップと作業単位
以前はリクエストごとに 1 つの DataContext を使用していましたが、直面しているシナリオによって異なります。L2S のポイントは、作業単位ごとにコンテキストがある作業単位パターンで使用することだったと思います。ただし、後でエンティティを新しいコンテキストに再アタッチするのはかなり難しいため、大規模なアプリケーションではうまく機能しません。
Rick Strahl は、このトピックについて非常に優れた紹介をしています。
http://www.west-wind.com/weblog/posts/246222.aspx
過去に問題があったと言えることの 1 つは、シナリオの読み取りと書き込みの両方に対して 1 つのコンテキストを使用することです。データコンテキストで行われる変更の追跡は、読み取りだけではかなりのオーバーヘッドになります。これは、ほとんどの Web アプリケーションがほとんどの場合行う傾向があることです。datacontext を読み取り専用にすることができ、それによって処理がかなり高速化されますが、書き込みには別のコンテキストが必要になります。