Je sais que la plupart des gens recommandent d'utiliser HttpRuntime.Cache parce qu'il a plus de flexibilité ... etc Mais que faire si vous voulez que l'objet persiste dans le cache pour la vie de l'application ? Y a-t-il un gros inconvénient à utiliser l'objet Application [] pour mettre en cache des choses?HttpRuntime.Cache [] vs Application []
Tant que vous n'abusez pas de l'état de l'application, je ne vois aucun problème à l'utiliser pour les éléments que vous ne voulez pas expirer. Sinon j'utiliserais probablement une variable statique près du code qui l'utilise. De cette façon, vous éviterez de passer par HttpApplicationState et serez obligé d'avoir une référence à System.Web si je veux accéder à mes données. Mais assurez-vous de réfléchir à la façon dont vous utilisez les objets que vous stockez dans HttpApplicationState. Si c'est un DataSet que vous continuez à ajouter à chaque requête, vous finirez par perdre trop de mémoire sur le serveur Web. La même chose peut se produire si vous continuez d'ajouter des éléments à HttpApplicationState lorsque vous traitez des demandes, à un moment donné vous forcerez l'application à redémarrer.
C'est probablement l'avantage d'utiliser Cache dans votre situation. Consommer de plus grandes quantités de mémoire n'est pas aussi fatal car vous autorisez ASP.NET à libérer les éléments de votre cache lorsque la mémoire se fait rare.
Utilisez le cache lorsque vous souhaitez que les éléments expirent automatiquement ou soient récupérés lorsque la mémoire est insuffisante. Dans le cas contraire, utilisez des variables statiques si vous le pouvez, car elles amélioreront les performances, puis exploreront la collection ApplicationState. Je ne suis pas sûr exactement ce qui serait le cas quand utiliser ApplicationState, mais il y en a sûrement.
L'application est déconseillée par le cache. Si vous avez besoin de quelque chose avec la portée de l'application, vous devez le créer en tant que membre statique d'une classe ou utiliser le cache. Si vous souhaitez utiliser la route de cache mais ne voulez jamais qu'elle expire, vous devez utiliser l'option CacheItemPriority.NotRemovable lorsque vous insérez la valeur dans le cache. Notez qu'il est possible d'utiliser cette priorité et d'utiliser toujours les dépendances de cache, par exemple si vos données dépendent de quelque chose dans le système de fichiers. Tout ce que CacheItemPriority fait est d'empêcher le HttpRuntime.Cache d'effacer intelligemment l'élément quand il ressent la pression de la mémoire et utilise son algorithme le moins utilisé récemment pour purger les éléments qui ne sont pas beaucoup utilisés.
Pourquoi dites-vous que l'application est obsolète? Je n'ai jamais vu ça nulle part et ce n'est pas indiqué dans la documentation. –
Parce que tout ce qu'il peut faire, Cache peut faire mieux. Il n'y a aucune raison que l'application existe maintenant que le cache existe, à l'exception de la rétrocompatibilité. – ssmith
Une autre petite raison de préférer le cache à l'application est que si les données sont sensibles, le cache est (légèrement) plus sécurisé. Le raisonnement ici est que le contenu de l'application est toujours affiché par défaut lorsque ASP.NET Trace est activé, soit au niveau de la page ou via Trace.axd. Comme cela pourrait arriver par accident, il serait facile de révéler publiquement quelque chose de sensible dans Application. Le contenu du cache n'est pas affiché dans la sortie Trace. – ssmith