HttpRuntime Cache和HttpContext Cache之间有什么区别？

Question

我知道有一个非常相似的问题here，但我希望能有更好的探索。如果HttpContext真的在幕后使用HttpRuntime.Cache，为什么我会使用HttpContext.Cache而不是HttpRuntime.Cache？

在文章Simulate a Windows Service using ASP.NET to run scheduled jobs中，Omar使用HttpContext来存储他的缓存项，但是当Jeff Atwood实现它here时，他选择使用HttpRuntime。显然，在这种特殊情况下，它是有道理的，因为您不必执行Web请求将缓存项添加回HttpContext。

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

Answer 1

最后它实际上是相同的缓存，只有HttpContext.Current有时可以为空（不在Web上下文中，或在Web上下文中但尚未构造）。您可以安全地使用HttpRuntime.Cache。

Answer 2

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

如果您正在做一些不在页面中的内容，您通常需要使用HttpRuntime.Cache来安全地访问它。

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

Answer 3

我发现它也有误导性，尽管我们都知道它只是在内部返回HttpRuntime.Cache。此外，HttpRuntime是一个不好的选择，我想要暴露Cache。

每个人都知道Session是会话级缓存，而我们所讨论的缓存是应用程序级别的。我希望将Application.Cache作为我们今天使用的缓存，并HttpContext.Cache来引用所谓的HttpContext.Items。

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