Qual è la differenza tra HttpRuntime Cache e HttpContext Cache?

Question

So che c'è una domanda molto simile here ma speravo di ottenere un'esplosione migliore. Perché dovrei utilizzare HttpContext.Cache invece di HttpRuntime.Cache se HttpContext utilizza davvero HttpRuntime.Cache dietro le quinte?

Nell'articolo Simulate a Windows Service using ASP.NET to run scheduled jobs Omar utilizza HttpContext per memorizzare gli elementi della cache, ma quando Jeff Atwood l'ha implementato, here, ha scelto di utilizzare invece HttpRuntime. Ovviamente in questa particolare situazione ha senso dal momento che non devi fare una richiesta web per aggiungere nuovamente l'elemento cache in HttpContext.

Tuttavia, sto cercando alcuni buoni suggerimenti su quando utilizzare l'uno rispetto all'altro.

Answer 1

È davvero la stessa cache alla fine, solo HttpContext.Current a volte può essere nullo (quando non è in un contesto Web o in un contesto Web ma non ancora costruito). Saresti sicuro di usare sempre HttpRuntime.Cache.

Answer 2

Quando si è in una normale pagina Web, è possibile utilizzare in modo sicuro HttpContext.Cache o solo la proprietà Cache della pagina.

Se si sta facendo qualcosa che non è in una pagina, è spesso necessario utilizzare HttpRuntime.Cache per accedere in modo sicuro ad esso.

In alcuni casi è possibile sapere se esiste o meno un contesto http, ad esempio se si avvia un thread separato da una pagina Web, quel thread non ha il contesto http. In altri casi è possibile che a volte sia presente un contesto http, come nel metodo Application_Start in global.asax, poiché l'applicazione potrebbe non essere sempre avviata in quanto esiste una richiesta.

Answer 3

Trovo ingannevole anche se tutti sappiamo che restituisce solo HttpRuntime.Cache internamente. Anche HttpRuntime è una specie di cattiva scelta per esporre la cache, suppongo.

Tutti sais come Session è la cache a livello di sessione e la cache di cui stiamo parlando è a livello di applicazione. Preferirei avere Application.Cache come cache che usiamo oggi e HttpContext.Cache per fare riferimento a ciò che è noto come HttpContext.Items.

Per quanto riguarda la risposta alla tua domanda, penso che dovremmo attenerci tutti a HttpRuntime.Cache rendendo il nostro codice più chiaro anche se disponiamo di vari modi per accedervi. E quando si pianifica seriamente di usarlo, è meglio avvolgere la propria API e chiamare internamente lo HttpRuntime's o qualsiasi altra implementazione della cache (EntLib, Velocity, ecc.).