Utilisation d'une variable statique pour mettre en cache des données

Question

Nous développons une application Windows Forms .NET 3.5, en utilisant LINQ to SQL et MVP. Nous avons une classe DataRepository pour récupérer des données:

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

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

    return _users; 
    } 

Afin de mettre en cache la liste des utilisateurs à travers toutes les instances du DBUserRepository, nous allions Caching Application Block de l'Enterprise Library.

Mais cela m'est arrivé, est-ce que je ne pouvais pas faire de _users un membre statique? Pour une raison quelconque, cela ressemble à une façon de «vieille école», mais cela fonctionne. Y a-t-il des inconvénients à le faire? Est-ce considéré comme un mauvais design?

private static IList<UserName> _users; 

Merci

Answer 1

Le plus grand inconvénient de ce faire est exactement ce que signifie static; Bien que vous puissiez avoir plusieurs objets DbUserRepository, ils ne partageront qu'une seule variable _users. Les cas où cela pose un problème:

• Si votre application devient de plus en multi-thread, et que vous voulez chaque thread d'avoir son propre référentiel utilisateur distinct (si c'est une préoccupation dépend de ce que le dépôt signifie dans la L'unité testant la classe DbUserRepository devient plus délicate, car si vous exécutez plusieurs tests unitaires sur cette classe, ils porteront l'état avec eux d'un test à l'autre, ce qui signifie que le test devient dépendant de l'ordre. ... ce qui est assez indésirable

Answer 2

pour la mise en cache simple, je pense que la variable statique est bien, juste besoin d'être un peu prudent sur l'utilisation des verrous pour protéger plusieurs threads accès la variable _users. Toutefois, une meilleure approche pourrait utiliser la classe Cache ASP.NET. Je sais que c'est dans l'espace de noms System.Web mais vous pouvez use it outside of ASP.NET application too.

Answer 3

Quelques éléments à considérer.

1. Sécurité des threads d'initialisation des variables
2. AppDomains. Les variables statiques sont locales à une instance AppDomain. Donc, si vous avez plusieurs AppDomains en cours d'exécution, vous aurez plusieurs instances du cache

Ceux-ci peuvent ou non être d'un intérêt pour votre application. Probablement pas, mais mérite d'être noté.

Answer 4

Si vous avez besoin de plus d'un d'entre eux, vous devrez faire un effort supplémentaire pour exciser le statique de votre code et commencer à le faire circuler partout.