ここに非常によく似た質問があることは知っていますが、より良い説明を得たいと思っていました。HttpContext が舞台裏で HttpRuntime.Cache を実際に使用している場合、なぜ HttpRuntime.Cache の代わりに HttpContext.Cache を使用するのでしょうか?
ASP.NET を使用して Windows サービスをシミュレートし、スケジュールされたジョブを実行するという記事で、 Omar は HttpContext を使用してキャッシュ項目を保存しますが、Jeff Atwood がここで実装したとき、代わりに HttpRuntime を使用することを選択しました。明らかに、この特定の状況では、キャッシュ項目を HttpContext に戻すために Web 要求を実行する必要がないため、これは理にかなっています。
ただし、どちらをいつ使用するかについて、いくつかの良い指針を探しています。
最終的には実際には同じキャッシュですが、HttpContext.Currentnull になることもあります (Web コンテキストではない場合、または Web コンテキストではあるがまだ構築されていない場合)。常に安全に使用できますHttpRuntime.Cache。
通常のWebページを表示しているときは、ページのプロパティHttpContext.Cacheだけを安全に使用できます。Cache
ページにないことをしている場合は、HttpRuntime.Cache安全にアクセスするために使用する必要があります。
場合によっては、httpコンテキストがあるかどうかを知ることができます。たとえば、Webページから別のスレッドを開始した場合、そのスレッドにはhttpコンテキストがありません。また、リクエストがあるためにアプリケーションが常に起動するとは限らないため、のApplication_Startメソッドのようにhttpコンテキストが存在する場合もあります。global.asax
HttpRuntime.Cache内部的に返されるだけであることは誰もが知っていますが、誤解を招くこともあります。また、HttpRuntime は、私が推測する Cache を公開するための一種の悪い選択です。
Sessionセッション レベルのキャッシュとはどのようなものか、誰もが言いますが、私たちが話しているキャッシュはアプリケーション レベルです。Application.Cache現在使用しているキャッシュとして を使用し、HttpContext.Cacheとして知られているものを参照したいと思いますHttpContext.Items。
あなたの質問への回答に関しては、さまざまな方法でアクセスできる場合でも、HttpRuntime.Cache に固執してコードをより明確にする必要があると思います。そして、それを真剣に使用する予定がある場合は、独自の API をラップして、内部的にHttpRuntime'sまたは他のキャッシュ実装 (EntLib、Velocity など) を呼び出すようにすることをお勧めします。