HttpRuntime Cache 和 HttpContext Cache 有什么区别？
我知道这里有一个非常类似的问题，但我是希望得到更好的解释。 如果 HttpContext 确实在幕后使用 HttpRuntime.Cache，为什么我要使用 HttpContext.Cache 而不是 HttpRuntime.Cache？
在文章使用 ASP.NET 模拟 Windows 服务运行计划作业 Omar使用 HttpContext 来存储他的缓存项，但是当 Jeff Atwood 在 此处 他选择使用 HttpRuntime。 显然，在这种特殊情况下，这是有意义的，因为您不必执行 Web 请求来将缓存项添加回 HttpContext。
然而，我正在寻找一些关于何时使用其中一种与另一种的好的建议。
I know there is a very similar question here but I was hoping to get a better explination. Why would I ever use HttpContext.Cache instead of HttpRuntime.Cache if the HttpContext really uses the HttpRuntime.Cache behind the scenes?
In the article Simulate a Windows Service using ASP.NET to run scheduled jobs Omar uses the HttpContext to store his cache items, but when Jeff Atwood Implemented it here he chose to use the HttpRuntime instead. Obviously in this particular situation it makes sense since since you don't have to do a web request to add the cache item back into the HttpContext.
However I'm looking for some good pointers as to when to use one versus the other.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
当您在常规网页中时，可以安全地使用
HttpContext.Cache或仅使用页面的Cache属性。如果您正在执行页面之外的操作，则通常需要使用 HttpRuntime.Cache 来安全地访问它。
在某些情况下，您可以知道是否存在 http 上下文，例如，如果您从网页启动一个单独的线程，则该线程没有 http 上下文。 在其他情况下，有时您可能有一个 http 上下文，例如在
global.asax中的Application_Start方法中，因为应用程序可能并不总是因为存在请求而启动。When you are in a regular web page, you can safely use
HttpContext.Cacheor just theCacheproperty of the page.If you are doing something that's not in a page, you often need to use
HttpRuntime.Cacheto safely get access to it.In some cases you can know if there is an http context or not, for example if you start a separate thread from a web page, that thread does not have http context. In other cases you may have an http context sometimes, like in the
Application_Startmethod inglobal.asax, as the application may not always be started because there is a request.我也发现它具有误导性，尽管我们都知道它只是在内部返回
HttpRuntime.Cache。 我认为 HttpRuntime 公开缓存也是一个糟糕的选择。大家都说
Session是会话级缓存，而我们所说的Cache是应用程序级缓存。 我更愿意使用Application.Cache作为我们今天使用的缓存，并使用HttpContext.Cache来引用所谓的HttpContext.Items。至于回答你的问题，我认为我们都应该坚持使用 HttpRuntime.Cache 来使我们的代码更清晰，即使我们确实有多种方法来访问它。 当您认真计划使用它时，您最好包装自己的 API 并在内部调用 HttpRuntime 或任何其他缓存实现（EntLib、Velocity 等）。
I find it misleading too although we all know it just returns
HttpRuntime.Cacheinternally. Also the HttpRuntime is kind of a bad choice to expose the Cache I guess.Everyone sais how
Sessionis session-level cache and the Cache we're talking about is application-level. I would prefer to haveApplication.Cacheas the cache we're using today andHttpContext.Cacheto refer to what's known asHttpContext.Items.As for answering your question, I think we should all stick to the HttpRuntime.Cache making our code clearer even if we do have various ways to access it. And when you seriously plan to use it you'd better wrap your own API and have that internally call the
HttpRuntime'sor any other cache implementation (EntLib, Velocity, etc...).最后它确实是相同的缓存，只是
HttpContext.Current有时可以为 null（当不在 Web 上下文中，或在 Web 上下文中但尚未构造时）。 始终使用 HttpRuntime.Cache 是安全的。It really is the same cache at the end, only
HttpContext.Currentcan sometimes be null (when not in a web context, or in a web context but not yet constructed). You'd be safe to always useHttpRuntime.Cache.