Quelle est la différence entre le HttpRuntime Cache et le HttpContext Cache?
-
12-09-2019 - |
Question
Je sais qu'il ya une question très similaire mais j'espérais mieux explination. Pourquoi devrais-je utiliser jamais HttpContext.Cache au lieu de HttpRuntime.Cache si le HttpContext utilise vraiment la HttpRuntime.Cache dans les coulisses?
Dans l'article Simuler un service Windows en utilisant ASP.NET pour exécuter des tâches planifiées Omar utilise le HttpContext pour stocker ses éléments de cache, mais quand Jeff Atwood Mis en œuvre il ici il a choisi d'utiliser le HttpRuntime à la place. Il est évident que dans cette situation particulière, il est logique puisque puisque vous n'avez pas à faire une demande Web pour ajouter l'élément de cache de nouveau dans le HttpContext.
Cependant, je suis à la recherche de quelques bons pointeurs à quand utiliser un par rapport à l'autre.
La solution
Il est vraiment le même cache à la fin, ne HttpContext.Current
peut parfois être nulle (lorsqu'ils ne sont pas dans un contexte web ou dans un contexte Web, mais pas encore construit). Vous seriez sûr d'utiliser toujours HttpRuntime.Cache
.
Autres conseils
Lorsque vous êtes dans une page Web régulière, vous pouvez utiliser en toute sécurité HttpContext.Cache
ou tout simplement la propriété Cache
de la page.
Si vous faites quelque chose qui n'est pas dans une page, vous avez souvent besoin d'utiliser HttpRuntime.Cache
pour obtenir en toute sécurité l'accès.
Dans certains cas, vous pouvez savoir s'il y a un contexte http ou non, par exemple, si vous démarrez un thread séparé à partir d'une page Web, ce thread n'a pas de contexte http. Dans d'autres cas, vous pouvez avoir un contexte http parfois, comme dans la méthode Application_Start
dans global.asax
, que l'application ne peut pas toujours être démarré parce qu'il ya une demande.
Je trouve trompeur aussi bien que nous le savons tous retourne juste HttpRuntime.Cache
interne. De plus, le HttpRuntime est une sorte de mauvais choix pour exposer le cache, je suppose.
Tout le monde SAIS comment Session
est cache niveau de la session et le cache dont nous parlons est au niveau de l'application. Je préférerais avoir Application.Cache
que le cache que nous utilisons aujourd'hui et HttpContext.Cache
de se référer à ce qu'on appelle HttpContext.Items
.
Quant à répondre à votre question, je pense que nous devrions tous tenir à la HttpRuntime.Cache rendre notre code plus clair, même si nous avons plusieurs façons d'y accéder. Et lorsque vous planifiez sérieusement l'utiliser, vous feriez mieux d'envelopper votre propre API et ont qui font appel à l'interne le HttpRuntime's
ou toute autre mise en œuvre du cache (EntLib, vitesse, etc ...).