我有一个简单的Windows窗体应用程序，它是用C＃4.0编写的。该应用程序显示了数据库中的一些记录。该应用程序具有由用户启动的查询选项。
我们可以将数据库中的记录称为作业 考虑两列JobID和Status
这些服务由两个背景服务更新，这些服务实际上像生产者消费者服务一样工作。这些服务的状态将由后面运行的这些服务更新。
现在，对于可以选择查询数据库记录的用户，可以说是例如根据状态查询数据（已提交，处理，已完成）。这可能导致数千条记录，并且GUI可能会在显示这些大量数据时遇到一些性能故障。
因此，将查询结果的块显示为页面非常重要。在用户手动刷新或进行新查询之前，不会刷新GUI。
说...由于从服务中不断更新作业，因此任何时间点的作业状态可能不同。页面在从DB获取数据时应具有数据的基本要求。
我正在使用LINQ to SQL从数据库中获取数据。它使用起来非常简单，但是不需要满足这种需求的中级缓存。如果记录数量非常高，使用进程内存来缓存结果可以将页面内存发送到极致。不幸的是，LINQ没有为DataContext对象提供任何中间层缓存工具。
使用C＃4.0 + SQL Server + Windows环境实现分页机制的首选方法是什么？
我觉得有些替代方案可能会有一个重复的表/数据库，可以暂时将结果存储为缓存。或者使用企业应用程序库的应用程序缓存块。我相信这是大多数开发人员面临的典型问题。哪种方法是解决此问题的最有效方法。 （注意：我的应用程序和数据库在同一个盒子上运行）
答案 0 :(得分：1)
虽然缓存是提高性能的可靠方法，但正确实施缓存策略可能比看起来更困难。问题是管理缓存过期或基本上确保缓存同步到所需程度。因此，在考虑缓存之前，首先考虑是否需要缓存。基于我可以从问题中收集的内容，似乎数据模型相对简单并且不需要任何连接。如果是这种情况，为什么不优化表和索引的分页？ SQL Server和Linq To SQL将以透明的方式轻松处理数千条记录的分页。
说明一次显示太多记录对于GUI来说是非常正确的，并且对用户来说也是禁止的。没有用户希望在任何给定时间看到比填充屏幕更多的记录。考虑到在用户请求之前不需要刷新数据的约束，应该可以安全地假设查询的数量相对较少。数据库与应用程序位于同一个框中的附加约束进一步巩固了您不需要缓存的点。 SQL服务器已在内部进行缓存。
有关性能调优的所有建议都表明您应该在尝试进行优化之前分析和测量性能。作为Donald Knuth的状态，过早的优化是万恶之源。