Quelle est la différence entre le cache HttpRuntime et le cache HttpContext?

Question

Je sais qu'il y a une question très similaire here mais j'espérais obtenir une meilleure explination. Pourquoi devrais-je jamais utiliser HttpContext.Cache au lieu de HttpRuntime.Cache si le HttpContext utilise vraiment le HttpRuntime.Cache dans les coulisses?

Dans l'article Simulate a Windows Service using ASP.NET to run scheduled jobs Omar utilise le HttpContext pour stocker ses éléments de cache, mais lorsque Jeff Atwood l'a implémenté here, il a choisi d'utiliser HttpRuntime à la place. Évidemment, dans cette situation particulière, il est logique puisque vous n'avez pas besoin de faire une requête Web pour ajouter l'élément de cache dans le HttpContext.

Cependant, je suis à la recherche de bons conseils pour savoir quand utiliser l'un plutôt que l'autre.

Answer 1

C'est vraiment le même cache à la fin, seulement HttpContext.Current peut parfois être nul (quand ce n'est pas dans un contexte web, ou dans un contexte web mais pas encore construit). Vous seriez sûr de toujours utiliser HttpRuntime.Cache.

Answer 2

Lorsque vous êtes dans une page Web classique, vous pouvez utiliser en toute sécurité HttpContext.Cache ou seulement la propriété Cache de la page.

Si vous faites quelque chose qui n'est pas dans une page, vous devez souvent utiliser HttpRuntime.Cache pour y accéder en toute sécurité.

Dans certains cas, vous pouvez savoir s'il existe 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 parfois avoir un contexte http, comme dans la méthode Application_Start dans global.asax, car l'application peut ne pas toujours être démarrée car il y a une requête.

Answer 3

Je trouve cela trompeur aussi bien que nous sachions tous qu'il renvoie juste HttpRuntime.Cache en interne. En outre, le HttpRuntime est un mauvais choix pour exposer le cache.

Tout le monde sait comment Session est un cache de niveau session et le cache dont nous parlons est au niveau de l'application. Je préférerais avoir Application.Cache comme cache que nous utilisons aujourd'hui et HttpContext.Cache pour faire référence à ce qu'on appelle . Pour ce qui est de répondre à votre question, je pense que nous devrions tous nous en tenir au HttpRuntime.Cache pour rendre notre code plus clair même si nous avons plusieurs façons d'y accéder. Et quand vous envisagez sérieusement de l'utiliser, vous feriez mieux d'utiliser votre propre API et d'appeler en interne le HttpRuntime's ou toute autre implémentation de cache (EntLib, Velocity, etc ...).