¿Cuál es la diferencia entre HttpRuntime Cache y HttpContext Cache?

Question

Sé que hay una pregunta muy similar here pero esperaba obtener una mejor explicación. ¿Por qué alguna vez usaría HttpContext.Cache en lugar de HttpRuntime.Cache si el HttpContext realmente usa HttpRuntime.Cache detrás de escena?

En el artículo Simulate a Windows Service using ASP.NET to run scheduled jobs Omar usa el HttpContext para almacenar sus elementos de caché, pero cuando Jeff Atwood lo implementó here eligió usar el HttpRuntime en su lugar. Obviamente, en esta situación particular tiene sentido ya que no tiene que hacer una solicitud web para volver a agregar el elemento de caché al HttpContext.

Sin embargo, estoy buscando algunos buenos consejos sobre cuándo usar uno frente al otro.

Answer 1

Realmente es la misma caché al final, solo HttpContext.Current a veces puede ser nulo (cuando no está en un contexto web, o en un contexto web pero aún no está construido). Estar seguro usar siempre HttpRuntime.Cache.

Answer 2

Cuando se encuentra en una página web normal, puede usar HttpContext.Cache de forma segura o simplemente la propiedad Cache de la página.

Si está haciendo algo que no está en una página, a menudo necesita usar HttpRuntime.Cache para tener acceso de manera segura.

En algunos casos, puede saber si hay un contexto http o no, por ejemplo, si inicia un hilo separado de una página web, ese hilo no tiene contexto HTTP. En otros casos, puede tener un contexto http a veces, como en el método Application_Start en global.asax, ya que la aplicación no siempre se puede iniciar porque hay una solicitud.

Answer 3

También me parece engañoso, aunque todos sabemos que devuelve HttpRuntime.Cache internamente. Además, el HttpRuntime es una mala elección para exponer el Caché, supongo.

Todo el mundo sabe cómo Session es el caché de nivel de sesión y el caché del que hablamos es a nivel de aplicación. Preferiría tener Application.Cache como el caché que estamos usando hoy y HttpContext.Cache para referirnos a lo que se conoce como HttpContext.Items.

En cuanto a la respuesta a su pregunta, creo que todos deberíamos ceñirnos al HttpRuntime.Cache que hace que nuestro código sea más claro incluso si tenemos varias formas de acceder a él. Y cuando realmente planee usarlo, será mejor que ajuste su propia API y que internamente llame al HttpRuntime's o cualquier otra implementación de caché (EntLib, Velocity, etc ...).