¿Está bien utilizar HttpRuntime.Cache fuera de las aplicaciones ASP.NET?

Scott Hanselman says yes.¿Está bien utilizar HttpRuntime.Cache fuera de las aplicaciones ASP.NET?

Añadir System.Web a su proyecto no web es una buena manera de hacer entrar en pánico a la gente. Otra es agregar una referencia a Microsoft.VisualBasic en una aplicación C#. Sin embargo, ambas son cosas útiles razonables y difíciles de hacer.

MSDN says no.

La clase Cache no está pensada para su uso fuera de las aplicaciones ASP.NET. Fue diseñado y probado para su uso en ASP.NET para proporcionar almacenamiento en caché para aplicaciones web. En otros tipos de aplicaciones, como aplicaciones de consola o aplicaciones de Windows Forms, el almacenamiento en caché de ASP.NET podría no funcionar correctamente.

Entonces, ¿qué debería pensar?

Fuente

2008-10-01 Jakub Šturc

+1 para la pregunta: Me gustaría ver una respuesta autorizada, es decir, ¿por qué MSDN dice no y cuáles son los problemas específicos de su uso fuera del entorno ASP.NET. Lo he usado en bibliotecas de clases que se usan desde el lado del cliente sin ningún problema. – Joe

Microsoft dice que sí: [Usando el caché ASP.NET en aplicaciones no web] (http://msdn.microsoft.com/en-us/library/Ee817647%28pandp.10%29.aspx) – lsalamon

Me doy cuenta de que esta pregunta es antigua, pero con el interés de ayudar a cualquiera que encuentre esto a través de la búsqueda, vale la pena señalar que .net v4 incluye una nueva caché de propósito general para este tipo de escenario. Está en el espacio de nombres System.Runtime.Caching:

https://msdn.microsoft.com/en-us/library/dd997357(v=vs.110).aspx

La referencia estática a la instancia de caché predeterminada es: MemoryCache.Default

Fuente

2010-05-05 08:08:48

System.Runtime.Caching no está en el perfil del cliente, para usarlo necesita el Framework completo, por lo que es un poco inútil para una aplicación de cliente. –

@Juan - sí, es lamentable que no se haya incluido en el perfil del cliente. Según el informe de error, Microsoft planea moverlo allí eventualmente. Puede mostrar su apoyo para la corrección votando: https://connect.microsoft.com/VisualStudio/feedback/details/558309/move-system-runtime-caching-dll-to-client-framework –

¿Por qué no se evita la pregunta por completo y utiliza el Caching Block of Enterprise Library? Podría usar System.Web.Caching, pero probablemente no obtendrá soporte de Microsoft si se encuentra con problemas y levantará las cejas para que no valga la pena.

Fuente

2008-10-01 17:21:18 Bryant

Imho Enterprise Library es bien, pero un poco pesado para algunos usos. –

¡Definitivamente no obtendrá soporte para Enterprise Library! – Joe

EntLib es un uso y una configuración más difíciles. –

Una cosa a tener en cuenta es que Microsoft ha lanzado el paquete de configuración de perfil de cliente de .NET Framework. Esta es una versión del framework 3.5 que se dirige a las aplicaciones cliente y tiene una huella reducida. El perfil de cliente no incluye los elementos de ASP.NET del marco.

Si su aplicación depende de System.Web, su aplicación no podrá aprovechar el perfil del cliente.

Ver Scott Gu's Blog para más detalles.

Fuente

2008-10-01 17:22:29 Brownie

No lo utilice, incluso si funciona, puede dejar de funcionar en el siguiente service pack/versión.

En el momento en que se hace algo con base en los detalles de la implementación interna y no en el contrato (en este caso, MSDN), es posible que tenga problemas en el futuro.

Fuente

2008-10-01 17:22:58 Nir

No debería haber ningún problema con el uso de HttpRuntime.Cache. Es una sofisticada tabla hash en memoria que puede ser muy útil fuera del contexto web. Aún así, podría ser un poco un olor a código hacer referencia a HttpRuntime.Cache en una aplicación no relacionada con Http, por lo que puede ser una buena idea colocarla detrás de alguna interfaz de ICache y usarla siempre que sea posible.

Fuente

2008-10-01 17:23:05

No parece haber nada en las versiones actuales de System.Web.Caching.Cache que dependen del tiempo de ejecución HTTP excepto por el método Insert() que acepta un CacheItemUpdateCallback, por lo que Scott es adecuado para la mayor parte.

Esto no impide que Microsoft modifique la clase en el futuro para estar más integrado con la infraestructura HTTP.

Escribí un WeakReference-based lightweight cache en otra respuesta.

Fuente

2008-10-01 17:27:57

Lo usé una vez, pero no se sentía bien y el IIRC aumentó la huella de memoria de forma bastante espectacular. En cambio, implementé mi propio mecanismo de caché liviano que es sorprendentemente fácil de hacer.

Utilizó la clase WeakReference que permitió a la memoria caché mantener referencias al objeto, pero también permite que el recolector de basura reclame la memoria si la referencia no se utiliza.

Lo único que no tenía era un hilo separado para limpiar los elementos obsoletos en el caché. Lo que sí hice fue que si el caché tenía> x elementos en él, revisaba todos los elementos almacenados en la memoria caché y quitaba los elementos viejos antes de agregar el nuevo.

Si necesita algo más robusto, use algo como MS Enterprise Library Caching Application Block.

Fuente

2008-10-01 20:35:55

Si usted está buscando una solución general: Esta es una situación típica para el enfoque de inyección de dependencia. Usando este enfoque, puede seguir a Scott Hanselman y MSDN!

Inyecte una dependencia System.Web como HttpRuntime.Cache sin tener una referencia System.Web en su biblioteca.

Fuente

2010-05-05 13:50:39

¿Está bien utilizar HttpRuntime.Cache fuera de las aplicaciones ASP.NET?

Respuesta

Cuestiones relacionadas