缓存 ListView 数据是一个可行的选择吗？答案

【问题标题】：Caching ListView data a viable option?缓存 ListView 数据是一个可行的选择吗？
【发布时间】：2009-05-28 22:57:43
【问题描述】：

这是我的场景： 1) 用户通过 LinqDataSource 运行搜索以检索要在 ListView 中显示的值。 2）他们点击其中一个项目，将他们带到另一个可以检查详细信息的页面，可以进行进一步的钻取等。 3) 用户想回到原来的ListView结果选择另一个项目进行检查。

我可以看到可以传递查询字符串参数，允许每次用户返回 ListView 时重复查询，但似乎应该有一种方法来缓存结果。

由于我使用的是 LinqDataSource，但我相信每次运行查询时都会获取实际结果。我目前正在向 e.Results 提供“选择新 {blah, blah}”类型的 IEnumerable，由于它填充了匿名类型，因此无法转换为 List。

简而言之： 1) 尝试在用户会话中放置可能较大的查询结果是否有意义？ 2）如果是，List是合理的数据结构吗？ 3) 我是否需要求助于创建具有正确属性的类来保存匿名数据、枚举查询返回、填充列表？ 4) 对于这种类型的目标，是否有比 LinqDataSource 更好的选择？ 5) 或者，每次点击 ListView 时运行查询是否更有意义？

如果不清楚，我深表歉意。如果有人能在我把一堆空闲时间引向错误的道路之前让我直截了当，我将不胜感激:)

【问题讨论】：

我应该提到，数据将特定于每个客户的搜索。

标签： asp.net linq linq-to-sql listview caching

【解决方案1】：

首先，我建议您查看 ASP.NET 附带的 caching mechanism，除非该数据对于某个用户是私有的。

其次，我建议您以某种方式设计应用程序，以便创建自然点，您可以在查询数据库之前尝试从缓存中获取数据（并将数据插入缓存，并使用过期规则），但是在您验证它确实会有所作为之前，不要开始将内容放入缓存中。

衡量实际花费了多少时间来检索数据并在产生影响的情况下使用缓存。

【讨论】：

+1，尽管我会颠倒这两点。 :) 每次他们点击列表视图时一定要运行查询，直到它被证明是一个问题。现代 RDBMS 可以处理的事情比许多人认为的要多，而且通常会提供自己的缓存层！

【解决方案2】：

我不确定从死里复活线程在 SO 上是否很酷，但这是我找到的回答这个问题的答案：

http://weblogs.asp.net/pwelter34/archive/2007/08.aspx

【讨论】：