httpcontext 中的 asp.net 缓存
我想缓存从数据库中提取的不经常修改的对象，因为每次页面加载时都会选择近 2000 个项目，导致页面加载期间出现明显的性能问题。
回顾这里和一些MSDN 文章（最相关的是 这里）似乎这些都是防止单个用户多次往返数据库的解决方案，并且一旦 httprequest 关闭，该缓存就会过期。
任何人都可以消除混乱，如果发现的话提供适用的参考吗？
I want to cache objects being pulled from a database that do not often get modified, because every time the page loads nearly 2000 items are selected, causing a noticable performance issue during page load.
After review here and a few MSDN articles (most relevant is here) it seems that these are solutions to prevent a single user from making multiple roundtrips to the database, and that this cache will expire once the httprequest is closed.
Can any one clear the confusion, providing an applicable reference if found?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您想要将项目存储在
HttpRuntime.Cache中，项目将在您的应用程序域的持续时间内存在于此处，它们会过期或被清除。无论哪一个先发生。请注意，这与指向HttpRuntime.Cache的HttpContext.Current.Cache完全相同。在服务层中调用后者更容易使用，因为您不必关心上下文是否存在。缓存始终存在。存储在 HttpContext.Current.Request.Items 中的项目仅在该请求期间存在。这对于存储可以通过应用程序的多个层读取/写入的单个请求信息非常有用。
You want to store the items in
HttpRuntime.Cacheitems will exist in here for the duration of your app domain, they expire, or are scavenged. Which ever happens first. Note this is exactly the same asHttpContext.Current.Cachewhich points toHttpRuntime.Cache. Invoking the later is easier to work with in service layers since you don't have to be concerned about whether a context exists or not. The cache always exists.Items stored in
HttpContext.Current.Request.Itemswill only exist for the duration of that request. This is useful for storing single request information that could be read / wrote through multiple layers of your application.