Implementar el caché correctamente en una biblioteca de clases para su uso en una aplicación asp.net

Question

Estoy implementando un caché en una biblioteca de clases que estoy usando en una aplicación asp.net.

Creé mi objeto de caché como un patrón único con un método estático para actualizar el caché que realmente solo está cargando una variable/propiedad miembro con una colección de datos que necesito en caché (por supuesto tiene una lógica de bloqueo). Pensé que era una buena manera de ir ya que sólo puedo acceder a mis datos llamando

MyCacheObject.Instance.MyDataCollection 

Estoy creando un nuevo objeto de caché para almacenar una bastante grande cantidad de datos divididos por alguna clave. Lo que estoy diciendo es que estoy creando una nueva memoria caché, pero esta no cargará todos los datos a la vez, sino que almacenará una colección para cada clave a la que se acceda.

MyOtherCacheObject.Instance.MyOtherDataCollection(indexkey) 

Esta vez se planteó la cuestión de la recolección de basura. Dado que estoy almacenando una gran cantidad de datos, ¿no sería un desperdicio si se tratara de gc'ed de repente? Como solo se trata de un patrón único, no hay nada que garantice que los datos permanezcan en la memoria caché.

Así que mi pregunta es: ¿cuál es la mejor práctica para implementar un caché para manejar esta situación? Realmente no me gusta una gran solución compleja para esto, y sé que hay almacenamiento en caché en System.Web, pero eso parece un poco "inactivo" ya que esta es solo una biblioteca de clases, ¿o qué piensas?

Answer 1

En mi opinión, la mejor solución sería tener las siguientes características:

• utiliza los servicios de almacenamiento en caché disponibles proporcionados por la plataforma tratando de evitar escribir el suyo propio.

• No acopla su biblioteca de clase a System.Web, para que las capas sean coherentes.

• Pero si la biblioteca de clases se ejecuta dentro de una aplicación ASP.NET la solución no debería requerir traer otra implementación de caché (por ejemplo, Enterprise Library Caching Application Block), que requiere configuración y configuración adicionales.

Por lo tanto, me gustaría utilizar una estrategia de la COI con el fin de permitir que la biblioteca de clase que se utiliza diferentes implementaciones de almacenamiento en caché, con base en el entorno que se está ejecutando.

suponga que define el contrato de almacenamiento en caché abstracto como:

public interface ICacheService 
{ 
    AddItem(...); 
} 

Usted puede proporcionar una implementación basada en System.Web:

public AspNetBasedCacheService : ICacheService 
{ 
    AddItem(...) 
    { 
     // Implementation that uses the HttpContext.Cache object 
    } 
} 

Y entonces que la aplicación 'publicado' como producto único. Tenga en cuenta que la diferencia con su enfoque original es que el singleton es solo una referencia a la implementación basada en el servicio de caché ASP.NET, en lugar del completo 'objeto de caché'.

public class ChacheServiceProvider 
{ 
    public static IChacheService Instance {get; set;} 

} 

Usted tendría que inicializar la aplicación chaching ya sea mediante la realización de inicialización perezosa, o al inicio de la aplicación (en global.asax.cs)

Y cada componente de dominio sería capaz de utilizar el servicio de almacenamiento en caché publicada sin saber que se implementa en base a System.Web.

// inside your class library: 
IChacheService chache = CacheServiceProvider.Instance; 
cache.AddItem(...); 

Estoy de acuerdo que probablemente no es la solución más simple, pero estoy con el objetivo de aprovechar la aplicación caché de ASP.NET sin sacrificar el código de desacoplamiento y flexibilidad.

Espero que haya entendido bien su pregunta.

Answer 2

Los datos no se recogerán en la basura, siempre y cuando la memoria caché todavía tenga una referencia a la misma.

Además, nunca use Singletons.