HttpRuntime缓存和HttpContext缓存有什么区别？

Question

我知道有一个非常相似的问题在这里，但我希望得到更好的解释。如果HttpContext实际上在幕后使用HttpRuntime.Cache，那么我为什么要使用HttpContext.Cache呢？

在文章“使用ASP.NET模拟Windows服务来运行计划任务”中，Omar使用HttpContext存储缓存项，但是Jeff Atwood在这里中选择使用了HttpRuntime。显然，在这种特定情况下，这样做是有意义的，因为您不必进行Web请求即可将缓存项添加回HttpContext。

但是，我正在寻找一些关于何时使用其中之一的好指针。

- Micah

Answer 1

实际上，最终使用的是相同的缓存，只不过HttpContext.Current有时可能为空（当不在Web上下文中时，或者在Web上下文中但尚未构建时）。您可以始终使用HttpRuntime.Cache来确保安全。

- Doron Yaacoby

Answer 2

当您在常规网页中时，可以安全地使用HttpContext.Cache或页面的Cache属性。

如果您正在执行不在页面中的操作，则通常需要使用HttpRuntime.Cache来安全地访问它。

在某些情况下，您可以知道是否存在http上下文，例如，如果您从网页启动单独的线程，则该线程没有http上下文。在其他情况下，有时可能会有http上下文，例如在global.asax的Application_Start方法中，因为应用程序可能并不总是因请求而启动。

- Guffa

Answer 3

我也觉得这很容易误导人，尽管我们都知道它只是在内部返回HttpRuntime.Cache。此外，我认为将Cache暴露在HttpRuntime中是一个不好的选择。

每个人都说Session是会话级别的缓存，而我们谈论的Cache是应用程序级别的。我更喜欢使用今天我们正在使用的Application.Cache作为缓存，而HttpContext.Cache则指代所谓的HttpContext.Items。

至于回答你的问题，我认为我们应该坚持使用HttpRuntime.Cache，即使我们有各种访问它的方式，以使我们的代码更清晰。当你真正计划使用它时，最好包装自己的API，并在内部调用HttpRuntime或任何其他缓存实现（EntLib、Velocity等）。

- user134706