Windows 窗体应用程序的中间层缓存

Question

我有一个用 C# 4.0 编写的简单 Windows 窗体应用程序。该应用程序显示了数据库中的一些记录。该应用程序具有由用户发起的查询选项。

我们可以将数据库中的记录称为作业 考虑两列 JobID 和 Status

这些由两个后台服务更新，实际上就像生产者消费者服务一样工作。作业的状态将由后面运行的这些服务更新。

现在对于可以选择从数据库中查询记录的用户来说，例如根据状态（提交、处理、完成）查询数据。这可能会导致数以千计的记录，并且 GUI 在显示这些数据时可能会遇到一些性能故障。

因此，将查询结果的块显示为页面很重要。在用户手动刷新或进行新查询之前，不会刷新 GUI。

例如说由于服务不断更新作业，因此作业状态在任何时间点都可能不同。页面应具有从数据库中获取数据时的数据的基本要求。

我正在使用 LINQ to SQL 从数据库中获取数据。它很容易使用，但不需要中级缓存来满足这种需求。如果记录的数量非常多，使用进程内存来缓存结果会导致页面内存暴涨到极致。不幸的是，LINQ 没有为 DataContext 对象提供任何中间层缓存设施。

在 C# 4.0 + SQL Server + Windows 环境下实现分页机制的优选方式是什么？

我觉得有些替代方案可以有一个重复的表/数据库，可以将结果临时存储为缓存。或者使用 Enterprise Application Library 的 Application Cache Block。相信这是大部分开发者面临的典型问题。这是解决此问题的最有效方法。 （注意：我的应用程序和数据库在同一个盒子上运行）

Answer 1

虽然缓存是提高性能的可靠方法，但正确实施缓存策略可能比看起来更困难。问题是管理缓存过期或基本上确保缓存同步到所需的程度。因此，在考虑缓存之前，请首先考虑是否需要它。根据我从问题中收集到的信息，数据模型似乎相对简单，不需要任何连接。如果是这样，为什么不优化分页的表和索引呢？ SQL 服务器和 Linq To SQL 将透明且轻而易举地处理数千条记录的分页。

您说一次显示太多记录对 GUI 来说是禁止的，对用户来说也是禁止的，这是正确的。在任何给定时间，没有用户希望看到比填充屏幕更多的记录。考虑到数据在用户请求之前不需要刷新的约束，可以安全地假设查询的数量会相对较低。数据库与应用程序在同一个盒子上的附加约束进一步巩固了您不需要缓存的观点。 SQL Server 已经在内部进行缓存。

所有关于性能调整的建议都表明您应该在尝试进行优化之前分析和衡量性能。正如Donald Knuth 所说，过早优化是万恶之源。