Usando una variable estática para almacenar en caché los datos

Question

Estamos desarrollando una aplicación .NET 3.5 Windows Forms, utilizando LINQ to SQL y MVP. Tenemos una clase DataRepository para la recuperación de datos:

public class DbUserRepository : IUserRepository 
{ 
    private IList<UserName> _users; 

    public IList<UserName> GetUserNames() 
    { 
    if (_users == null) 
    { 
     // retrieve _users from DB 
    } 

    return _users; 
    } 

Con el fin de almacenar en caché la lista de usuarios a través de todas las instancias del DBUserRepository, nos iban a utilizar el almacenamiento en caché bloque de aplicación de la Enterprise Library.

Pero se me ocurrió, ¿no podría simplemente hacer _users un miembro estático? Por alguna razón, parece una forma de "vieja escuela", pero funciona. ¿Hay algún inconveniente para hacer esto? ¿Esto se considera un mal diseño?

private static IList<UserName> _users; 

Gracias

Answer 1

La desventaja más grande de hacer esto es exactamente debido a lo que significa static; aunque puede tener muchos objetos DbUserRepository, siempre solo compartirán una variable _users. Los casos en que esto causa problemas:

• Si su aplicación cada vez se convierte en multi-hilo, y desea que cada hilo tenga su propio repositorio distinta del usuario (si es o no es una preocupación depende de lo que significa el repositorio en el contexto de su sistema)

• La prueba de la clase DbUserRepository se vuelve más complicada, porque si ejecuta pruebas de unidad múltiple en esta clase, llevarán el estado junto con ellas de prueba a prueba, lo que significa que la prueba pasa a depender del orden ... que es bastante indeseable

Answer 2

para el almacenamiento en caché sencilla creo variable estática está bien, sólo tiene que ser un poco cuidadoso con el uso de bloqueos para proteger múltiples hilos con el acceso a la variable _users. Sin embargo, un mejor enfoque podría ser el uso de la clase ASP.NET Cache. Sé que está en el espacio de nombres System.Web pero puede use it outside of ASP.NET application too.

Answer 3

Algunas cosas a tener en cuenta.

1. Seguridad para subprocesos de inicializar las variables
2. dominios de aplicación. Las variables estáticas son locales a una instancia de AppDomain. Por lo tanto, si tiene varios AppDomains en ejecución, tendrá varias instancias del caché

Estos pueden o no ser de interés para su aplicación. Probablemente no, pero vale la pena señalar.

Answer 4

Si alguna vez necesita más de uno de ellos, tendrá que hacer un esfuerzo extra para eliminar el estático de su código y comenzar a pasarlo por todos lados.