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

Question

我有一个简单的Windows Forms应用程序，它被编写为C＃4.0。该应用程序显示数据库中的一些记录。该应用程序具有由用户启动的查询选项。

在数据库中的记录，我们可以称之为乔布斯 考虑两列作业ID和状态

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

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

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

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

我正在使用LINQ to SQL从数据库中获取数据。它使用起来非常简单，但没有必要满足这种需求的中级缓存。如果记录数量非常高，使用进程内存来缓存结果可以将页面内存激增至极限。不幸的是，LINQ不提供任何中间层缓存设施与DataContext对象。

用C＃4.0 + SQL Server + Windows环境实现分页机制的最佳方式是什么？

一些替代方案我觉得有一个可以临时存储结果作为缓存的复制表/ DB。或者使用进取的应用程序库的应用程序缓存块。我相信这是大多数开发人员面临的典型问题。这是解决这个问题的最有效的方法。 （注意：我的应用程序和数据库在同一个机器上运行）

Answer 1

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

你是正确的，指出一次显示太多记录对于GUI来说是禁止的，并且对用户来说也是禁止的。没有用户希望在任何给定时间看到比填满屏幕更多的记录。考虑到在用户请求之前不需要刷新数据的限制，假设查询的数量相对较低应该是安全的。数据库与应用程序位于同一个框中的附加限制进一步巩固了您不需要缓存的点。 SQL服务器已经在内部进行缓存。

有关性能调整的所有建议都表明，在尝试进行优化之前，应该对性能进行配置并测量性能。如Donald Knuth所述，不成熟的优化是万恶之源。