Was ist der Unterschied zwischen dem HttpRuntime Cache und dem HttpContext Cache?

Question

Ich weiß, dass es eine sehr ähnliche Frage gibt here, aber ich hoffte, eine bessere Erkundung zu bekommen. Warum sollte ich jemals HttpContext.Cache anstelle von HttpRuntime.Cache verwenden, wenn der HttpContext wirklich den HttpRuntime.Cache hinter den Kulissen verwendet?

In dem Artikel Simulate a Windows Service using ASP.NET to run scheduled jobs Omar verwendet die Httpcontext seinen Cache Elemente zu speichern, aber wenn Jeff Atwood es Implementiert here er wählte stattdessen die Httpruntime zu verwenden. Offensichtlich ist es in dieser speziellen Situation sinnvoll, da Sie keine Web-Anfrage machen müssen, um das Cache-Element wieder in den HttpContext einzufügen.

Allerdings bin ich auf der Suche nach ein paar gute Hinweise, wann man einen gegen den anderen verwenden soll.

Answer 1

Es ist wirklich der gleiche Cache am Ende, nur HttpContext.Current kann manchmal null sein (wenn nicht in einem Webkontext oder in einem Webkontext, aber noch nicht konstruiert). Sie würden sicher sein, immer HttpRuntime.Cache zu verwenden.

Answer 2

Wenn Sie auf einer normalen Webseite sind, können Sie sicher HttpContext.Cache oder nur die Cache Eigenschaft der Seite verwenden.

Wenn Sie etwas tun, das nicht auf einer Seite ist, müssen Sie oft HttpRuntime.Cache verwenden, um sicher darauf zugreifen zu können.

In einigen Fällen können Sie wissen, ob ein http-Kontext vorhanden ist oder nicht. Wenn Sie beispielsweise einen separaten Thread von einer Webseite starten, hat dieser Thread keinen http-Kontext. In anderen Fällen haben Sie manchmal einen HTTP-Kontext, wie in der Application_Start-Methode in global.asax, da die Anwendung möglicherweise nicht immer gestartet wird, da eine Anforderung vorliegt.

Answer 3

Ich finde es auch irreführend, obwohl wir alle wissen, es gibt nur HttpRuntime.Cache intern zurück. Auch die HttpRuntime ist irgendwie eine schlechte Wahl, um den Cache freizulegen.

Jeder sagt, wie Session Sitzungslevel Cache ist und der Cache, über den wir sprechen, ist auf Anwendungsebene. Ich hätte lieber Application.Cache als den Cache, den wir heute verwenden, und HttpContext.Cache, um sich auf das zu beziehen, was als HttpContext.Items bekannt ist.

Wie zur Beantwortung Ihrer Frage, ich denke, wir sollten alle bei der HttpRuntime.Cache bleiben unseren Code klarer, auch wenn wir verschiedene Möglichkeiten haben, darauf zuzugreifen. Und wenn Sie ernsthaft planen, es zu verwenden, verpacken Sie besser Ihre eigene API und rufen Sie intern die HttpRuntime's oder jede andere Cache-Implementierung (EntLib, Velocity, etc ...).