14

Estoy utilizando la nueva .NET 4.0 Caching API, ObjectCache. He hecho algunas preguntas sobre esta área en los últimos días, y he insinuado este tema, pero pensé que valía la pena analizarlo en su propia pregunta.Seguridad de subprocesos y gestión de ámbito para .NET 4.0 ObjectCache

Como la clase es abstracta y todos los métodos son virtuales, esto significa que podemos crear nuestros propios proveedores de caché personalizados.

Según MSDN, ObjectCache no tiene que ser un singleton, y puede crear varias instancias de él en su aplicación.

Pero para mí, esto parece que también tenemos que gestionar la creación de instancias y el tiempo de vida de este objeto.

Tengo una aplicación web ASP.NET MVC 3, con StructureMap como contenedor de inyección de mi dependencia.

Quiero tener un único caché compartido para toda mi aplicación web.

Por lo tanto, creo una clase muy simple que envuelve la clase ObjectCache, y proporciona unboxing en la implementación de métodos.

La clase tiene una instancia de ObjectCache en el ctor, y fija a un privada instancia estática de la memoria caché, que los métodos (Añadir, Get, etc.) trabajan fuera.

Ej

public class CacheManager 
{ 
    private static ObjectCache _cache; 

    public CacheManager(ObjectCache cache) 
    { 
     _cache = cache; 
    } 

    // Add, Get, Remove methods work off _cache instance. 
} 

Ahora, aquí está mi registro DI:

For<CacheManager>().Singleton().Use<CacheManager>().Ctor<ObjectCache>("cache").Is(MemoryCache.Default); 

En Inglés: Cuando algo solicita una instancia CacheManager, utiliza una instancia singleton, y establezca el parámetro ObjectCache a ser una Instancia de MemoryCache.

Así que no es lo que tengo, ahora las preguntas:

  1. Si tengo una clase para envolver el ObjectCache, lo hace esta clase tiene que ser un producto único?
  2. MSDN dice que ObjectCache es seguro para subprocesos, pero ahora que estoy usando un singleton, ¿necesito algún tipo de bloqueo para mantener la seguridad del hilo?
  3. ¿La instancia privada de ObjectCache en mi clase contenedora debe ser estática? ¿La clase en sí necesita ser estática?
  4. Pensamientos generales sobre mi implementación general?

No he podido encontrar un blog decente/artículo sobre .NET ObjectCache en aplicaciones web ASP.NET, de ahí mi confusión.

Estoy acostumbrado a usar HttpContext.Current.Cache (que es estático) y no me importa la administración de por vida para la memoria caché.

Respuesta

6
  1. Dado que MemoryCache.Default es un singleton, su clase sin estado realmente no necesita ser una. Sin embargo, eso depende completamente de ti.
  2. No debería necesitar bloquearse alrededor de la instancia de ObjectCache.
  3. No, y No. Hacerlo estático no proporciona ningún valor. Indicar que es un singleton en StructureMap hace que GetInstance<>() siempre devuelva el mismo objeto de todos modos.
  4. El valor real de ajuste ObjectCache sería abstraer la implementación de la memoria caché para que pueda cambiarla o simularla. Sin una interfaz, esto se vuelve menos útil.

una implementación de ejemplo a continuación ...

public interface ICacheManager 
{ 
    // add, get, remove, etc 
} 

public class CacheManager : ICacheManager 
{ 
    private static ObjectCache _cache; 

    public CacheManager(ObjectCache cache) 
    { 
     _cache = cache; 
    } 

    // Add, Get, Remove methods work off _cache instance. 
} 

Entonces ...

For<ICacheManager>() 
    .Singleton() 
    .Use<CacheManager>(); 

For<ObjectCache>() 
    .Use(MemoryCache.Default); 

Si quieres que cambiar de proveedor de caché que sigue siendo un ObjectCache en el futuro, entonces es fácil de ajustar

Espero que esto ayude!

+0

Esa es la respuesta que estaba buscando. Gracias. Por cierto, ¿qué te hace pensar que 'MemoryCache.Default' es un singleton? – RPM1984

+0

Y también, normalmente usaría una interfaz, pero el tipo 'ObjectCache' es mi interfaz, ya que es una clase abstracta. Entonces, si quiero pasar a otro proveedor de caché, simplemente cambio el tipo de 'ObjectCache' que se inyecta en el ctor de la clase CacheManager. – RPM1984

+0

@Travis - ¿Algún comentario a lo anterior? – RPM1984