asp.net - ¿Cuál es la diferencia entre la memoria caché HttpRuntime y la memoria caché HttpContext?

caching httpruntime.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 HttpContext realmente usa HttpRuntime.Cache entre bambalinas?

En el artículo Simular un servicio de Windows usando ASP.NET para ejecutar trabajos programados, Omar usa HttpContext para almacenar sus elementos de caché, pero cuando Jeff Atwood lo implementó here , eligió usar HttpRuntime en su lugar. Obviamente, en esta situación en particular, tiene sentido, ya que no es necesario realizar una solicitud web para volver a agregar el elemento de caché en el HttpContext.

Sin embargo, estoy buscando algunos buenos indicadores de cuándo usar uno contra el otro.

Answer 1

Cuando se encuentra en una página web normal, puede usar HttpContext.Cache o solo la propiedad de 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 a él de manera segura.

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

Answer 2

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

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

En cuanto a responder a su pregunta, creo que todos deberíamos apegarnos a HttpRuntime.Cache haciendo que nuestro código sea más claro incluso si tenemos varias formas de acceder a él. Y cuando planeas usarlo seriamente, deberías envolver tu propia API y hacer que se llame internamente a HttpRuntime''s o cualquier otra implementación de caché (EntLib, Velocity, etc.).

Answer 3

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