Implémentation correcte du cache dans une bibliothèque de classes pour une utilisation dans une application asp.net

Question

J'implémente un cache dans une bibliothèque de classes que j'utilise dans une application asp.net.

J'ai créé mon objet cache en tant que modèle singleton avec une méthode statique pour mettre à jour le cache, qui charge en réalité une variable / propriété membre avec une collection de données à mettre en cache (avec une logique de verrouillage bien sûr). Je me suis dit que c’était un bon moyen d’aller puisque je peux simplement accéder à mes données en appelant

MyCacheObject.Instance.MyDataCollection

Je crée un nouvel objet de cache pour stocker une assez grande quantité de données partitionnées par une clé. Ce que je dis, c'est que je crée un nouveau cache, mais celui-ci ne chargera pas toutes les données à la fois, mais stockera plutôt une collection pour chaque clé utilisée.

MyOtherCacheObject.Instance.MyOtherDataCollection(indexkey)

Cette fois, la question de la récupération de place a été soulevée. Étant donné que je stocke une énorme quantité de données, ne serait-ce pas un gaspillage s'il était obtenu tout à coup? Puisqu'il ne s'agit que d'un modèle singleton, rien ne garantit que les données resteront dans le cache.

Ma question est donc la suivante: quelle est la meilleure pratique pour implémenter un cache afin de gérer cette situation? Je n'aime vraiment pas une solution complexe à cela, et je sais qu'il y a une mise en cache dans System.Web, mais cela semble un peu 'off' car il ne s'agit que d'une bibliothèque de classes, ou qu'en pensez-vous?

Answer 1

À mon avis, la meilleure solution aurait les caractéristiques suivantes:

• Utilise les services de mise en cache disponibles fournis par la plate-forme en essayant d'éviter d'écrire les vôtres.

• Ne couplez pas votre bibliothèque de classes à System.Web afin que les couches soient cohérentes.

• Toutefois, si la bibliothèque de classes est exécutée dans une application ASP.NET, la solution ne devrait pas nécessiter l'implémentation d'une autre implémentation de mise en cache (par exemple, le bloc d'application de mise en cache de bibliothèque d'entreprise), ce qui nécessite une configuration et une configuration supplémentaires.

J'utiliserais donc une stratégie IoC afin de permettre à la bibliothèque de classes d'utiliser différentes implémentations de mise en cache, en fonction de l'environnement sur lequel elle s'exécute.

Supposons que vous définissiez votre contrat de mise en cache abstrait comme suit:

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

Vous pouvez fournir une implémentation basée sur System.Web:

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

Et ensuite, cette implémentation est "publiée" en tant que singleton. Notez que la différence avec votre approche initiale est que le singleton est simplement une référence à l'implémentation basée sur le service de cache ASP.NET, au lieu de la totalité de "l'objet de cache".

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

}

Vous devez initialiser l'implémentation de chachage soit en effectuant une initialisation lente, soit au démarrage de l'application (dans global.asax.cs)

Et chaque composant de domaine pourrait utiliser le service de mise en cache publié sans savoir qu'il est implémenté sur System.Web.

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

Je conviens que ce n'est probablement pas la solution la plus simple, mais je souhaite tirer parti de la mise en œuvre du cache ASP.NET sans sacrifier le découplage du code et la flexibilité.

J'espère avoir bien compris votre question.

Answer 2

Les données ne seront pas récupérées tant que le cache en conservera une référence.

De même, n'utilisez jamais de singletons.