System.Web.Caching vs. Enterprise Library Caching Block

Question

Pour un composant .NET qui sera utilisé à la fois dans des applications Web et des applications client riche, il semble y avoir deux options évidentes pour la mise en cache : System.Web.Caching ou Ent. Lib. Caching Block.

• Qu'utilisez-vous ?
• Pourquoi ?

System.Web.Caching

Peut-on l'utiliser en dehors des applications Web ? J'ai vu des informations contradictoires, mais je pense que la réponse est peut-être, en quelque sorte, pas vraiment.

• un article de la KB mettant en garde contre l'utilisation des applications non web 1.0 et 1.1
• La page 2.0 comporte un commentaire qui indique que c'est OK : http://msdn.microsoft.com/en-us/library/system.web.caching.cache(VS.80).aspx
• Scott Hanselman est effrayé par cette notion.
• La page 3.5 comprend un a avertissement contre une telle utilisation
• Rob Howard utilisation encouragée en dehors des applications web

Je ne m'attends pas à utiliser l'un de ses points forts, SqlCacheDependency mais l'ajout de CacheItemUpdateCallback dans .NET 3.5 semble être une très bonne chose.

Bloc d'application de mise en cache de la bibliothèque d'entreprise

• d'autres blocs sont déjà utilisés et la dépendance existe déjà.
• la persistance du cache n'est pas nécessaire ; régénérer le cache au redémarrage est acceptable

Certains éléments du cache devraient toujours être disponibles, mais être rafraîchis périodiquement. Pour ces éléments, l'obtention d'un callback après un élément a été retiré n'est pas très pratique. Il semble qu'un client devra simplement dormir et interroger jusqu'à ce que l'élément du cache soit repeuplé.

Memcached pour Win32 + Client .NET

Quels sont les avantages et les inconvénients lorsque l'on n'a pas besoin d'une distribué cache ?

Answer 1

Ce sont les éléments que je considère pour le sujet de la mise en cache :

MemCached Win32 Vélocité Cache .net Enterprise Library Caching Application Block

MemCached Win32 : Jusqu'à récemment, j'ai utilisé MemCached Win32. C'est un peu comme une ferme web (plusieurs serveurs servant le même contenu pour une haute disponibilité) mais c'est une ferme de cache. Cela signifie que vous pouvez l'installer localement sur votre serveur web dans un premier temps si vous n'avez pas les ressources pour aller plus loin. Ensuite, au fur et à mesure que vous progressez, vous pouvez évoluer horizontalement (plus de serveurs) ou verticalement (plus de matériel). Il s'agit d'un produit qui a été porté à partir du MemCached original pour fonctionner sous Windows. Ce produit a été largement utilisé sur des sites à très fort trafic. http://lineofthought.com/tools/memcached

Vélocité : Il s'agit de la réponse de Microsoft à des produits tels que MemCached. MemCached est sorti depuis un certain temps, Velocity est en mode CTP. Je dois dire que d'après ce que j'ai lu jusqu'à présent, ce produit va certainement me faire tourner la tête une fois qu'il sera sorti. Mais je ne peux pas me résoudre à lancer de gros projets de production sur un produit CTP sans aucune expérience. J'ai tout de même commencé à jouer avec, car une fois qu'il aura pris de l'ampleur, MemCached ne sera même plus comparable pour ceux qui sont enfermés dans le monde Windows ! http://blogs.msdn.com/velocity/

.NET Cache : Il n'y a aucune raison de négliger le cache standard de .NET. Il est intégré et prêt à l'emploi, gratuitement et sans aucune configuration (majeure) requise. Il offre de la flexibilité en proposant des mécanismes pour stocker des éléments en mémoire locale, dans un serveur d'état UNIQUE ou dans une base de données centralisée. Velocity intervient lorsque vous avez besoin de plus d'un serveur à état unique (cache en mémoire) et que vous ne voulez pas utiliser une base de données lente pour stocker votre cache.

Bloc d'applications d'entreprise : Je me tiens à l'écart de tous les blocs d'applications d'entreprise. Ce sont des frameworks lourds qui offrent plus que ce dont j'ai généralement besoin ! Tant que vous n'oubliez pas d'envelopper tout ce qui touche au code qui n'est pas le vôtre et que vous suivez des règles simples de codage, préférez n'importe quelle autre méthode à celle-ci ! (Ce n'est que mon opinion, bien sûr - MySpace tire le meilleur parti possible des Enterprise Application Blocks).

Vous ne devez pas choisir à l'avance ! Je crée généralement un wrapper de cache avec lequel je communique dans mon code pour des méthodes telles que Get, Set, Exists, Remove, ListKeys, etc. Il pointe ensuite vers un niveau sous-jacent d'abstraction de cache qui peut pointer vers MemCached, Velocity ou le cache .NET. J'utilise StructureMap (ou je choisis un autre conteneur IoC) pour injecter la forme de cache que je veux utiliser pour un environnement donné. Dans ma boîte de développement locale, je peux utiliser le cache .NET dans la session. En production, j'utilise généralement MemCached Win 32. Mais quelle que soit la façon dont il est configuré, vous pouvez facilement intervertir les choses pour essayer chaque système et voir ce qui fonctionne le mieux pour vous. Vous devez simplement vous assurer que votre application en sait le moins possible sur la façon dont les choses sont mises en cache ! Une fois que cette couche d'abstraction est en place, vous pouvez alors faire des choses comme exécuter un algorithme de compression (gzip) pour toutes les données qui entrent et sortent du cache, ce qui vous permettrait de stocker 10 fois la quantité de données dans le cache. - de manière transparente .

J'aborde les thèmes du cache .NET, de MemCached Win32, de StructureMap et des abstractions appropriées dans mon livre, si cela vous intéresse !

ASP.NET 3.5 Réseaux sociaux ( http://www.amazon.com/ASP-NET-3-5-Social-Networking-Enterprise-ready/dp/1847194788/ref=sr_1_1?ie=UTF8&s=books&qid=1225408005&sr=8-1 ) Andrew Siemer www.andrewsiemer.com blog.andrewsiemer.com www.socialnetworkingin.net

Mise à jour Modification du lien qui répertorie les sites utilisant memcached. Merci à David d'avoir remarqué qu'il était cassé !

Answer 2

Gardez à l'esprit que la documentation d'EntLib vous oriente spécifiquement vers le cache ASP.NET pour les applications ASP.NET. C'est probablement la recommandation la plus forte pour l'utiliser ici. De plus, le cache EntLib n'a pas de dépendances, ce qui est pour moi une raison importante de ne pas l'utiliser.

Je ne pense pas qu'il y ait une limitation technique en tant que telle sur l'envoi de System.Web en tant que partie de votre application, bien que ce soit un peu étrange qu'ils aient mis cet avis sur la page .NET 3.5. Hanselman dit en fait qu'il a commencé par être effrayé par cette notion, mais qu'il s'est laissé convaincre. De plus, si vous lisez les commentaires, il dit que le bloc a trop de pièces mobiles et que le cache ASP.NET est beaucoup plus léger.
Je pense que c'est exactement le genre de problème que Vélocité va résoudre, mais ce n'est qu'un aperçu pour l'instant :-(

Je vous conseille d'utiliser Web.Caching et de voir comment vous vous en sortez. Si vous mettez une sorte de couche d'abstraction par-dessus, vous aurez toujours la possibilité de la remplacer par le bloc EntLib plus tard si vous rencontrez des problèmes.

Answer 3

Jetez un coup d'œil à memcached . Il s'agit d'un système de mise en cache distribué vraiment cool, rapide et léger. Il existe des API pour plusieurs des langages les plus populaires, dont C#. Il peut ne pas être utile du côté client (à moins bien sûr que le client n'obtienne les données mises en cache à partir d'un serveur quelconque), mais si vous abstrayez votre utilisation de memcached vers une interface spécifique, vous pouvez ensuite mettre en œuvre l'interface avec un autre système de mise en cache.

Answer 4

@Davide Vosti

"S'ils le mettent dans l'espace de noms web, je pense que c'est pour une bonne raison." Cette même logique s'applique-t-elle au Concurrency and Coordination Runtime (CCR) dans le studio robotique ? Non ? Je ne le pensais pas.