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所述，不成熟的優化是萬惡之源。