WCF/Silverlight/SQL數據庫緩存策略

Question

好吧，我有一個非常複雜的Silverlight應用程序，它從一個WCF服務（asp.net託管的服務層）獲取其數據，該服務又調用一個調用存儲過程的數據層SQL 2005 DB來提取所需的數據。所以往返是這樣的：

Silverlight應用程序 - > WCF服務 - >數據層 - >數據庫 - >數據層 - > WCF服務將數據實體轉換爲相應的DTO（數據傳輸對象）或List <> - > Silverlight App

大部分數據都是高度關聯的（所以它需要存在於數據庫中），但它很少會改變。看起來我有幾個位置選擇來緩存這個「半常數」數據：

1. 我可以將其緩存在數據層中。我的數據層已經設置爲使用SQLDependency類並緩存存儲過程調用的結果。我認爲這是或者可以是應用程序級緩存。
2. 我可以緩存在WCF服務本身的應用程序級別（或會話級別取決於調用）緩存結果的DTO。 （a）我甚至可以進一步通過將得到的DTO的XML序列化爲WCF服務端的文件，以便我可以（a）檢查內存緩存，然後（b）檢查文件緩存和（c）擊中數據層
3. 我可以在SL應用程序的客戶端使用隔離存儲來做類似於2（a）的操作。我可以使用散列（或者moddate或者其他）將數據序列化到本地隔離存儲，然後只需撥打一個電話即可檢查該數據。

還有一件事需要補充：我在IIS7中託管了這個WCF服務，並開啓了動態壓縮功能，以便（通常非常大且容易壓縮的）XML響應得到gzip-ed。理想情況下，我想IIS會緩存這個gzip-ed結果以避免所有額外的處理。我認爲它可能已經這樣做了，但我不確定。

我很確定最終答案是「它取決於」的某種味道，但我很想聽聽別人如何接近這個。 Do X的一個好的戰術方法，用工具Y測試性能，如果需要的話，做Z會很好。

幾個環節（我會添加到這個，因爲我研究這個）：

WCF Caching Approach

Answer 1

我認爲＃2是可維護性和架構你最好的選擇。 IIS提供緩存，爲什麼不使用它？

你不想從數據層引用System.Web。客戶端也不是最好的選擇，因爲你必須編寫一堆額外的代碼來保持數據同步。

Answer 2

System.Web緩存在ASP.NET兼容模式下運行時是否可用於WCF？可能最好不要依賴它並寫下你自己的。

另一方面，看看微軟的Velocity項目，看起來它會產生一個非常有趣的緩存技術，而不依賴於ASP.NET。

Answer 3

如果您的用戶數據變化非常少且需要快速響應，那麼基於本地存儲的自定義機制比等待服務器往返速度快得多。

Dino Sposito在MSDN雜誌上發佈了一篇有關本地存儲和緩存的有趣文章，您可以找到捕獲程序集的方法（想象一下只需加載所需的最小程序包，然後在後臺的其餘程序集中加載程序，性能火箭，你的代碼更復雜:)）。

正如你所說的是事情要放在一個平衡和決定。

HTH 布勞

Answer 4

我的做法是這樣的：

1. 確定是否確實存在具有性能問題
2. 衡量性能（是不是alreade接受我的用戶？）在每個teir上（數據庫提供數據需要多長時間？服務響應數據需要多長時間？從服務到客戶端需要多長時間？）
3. 基於測量人員然後我會決定在哪裏做我的緩存。請記住，緩存越接近數據存儲，緩存越容易，但越接近您執行緩存的客戶端，性能增益（通常）越好。

還要記住緩存不應該是改善性能的第一件事。您還應該考慮其他性能收益。存儲過程是否緩慢？ WCF消息中有很多開銷嗎？服務中是否存在一些低效的處理？我真的需要在一條消息中使用所有這些數據嗎？

HTH， 喬納森

Answer 5

我們最近剛剛實施的＃3，使用獨立存儲客戶端緩存。

在我們的應用程序中，我們有很多下拉菜單和自定義字段，每次載入時應用程序都會從​​服務器獲取這些字段。將這些數據移至IS確實有幫助。該應用程序現在打電話來檢查服務器上是否有任何更改，如果不是，則從IS加載數據，否則（很少）刷新IS。

這消除了大量的WCF調用和數據傳輸，SL頁面的加載時間更短，並且由於減少了網絡流量和數據庫訪問，應用程序通常變得更具可擴展性。

是的，涉及到一些編碼，但對最終用戶的好處是至關重要的。

安德魯

Answer 6

如果使用RIA服務，然後進行簡單的辦法是有兩個單獨的EDMX定義。一個用於緩存實體，一個用於事務性實體。

一個域上下文可以通過AddReference see引用另一個domaincontext上的實體。

緩存的實體可以在用戶認證後立即加載。爲了簡單起見，在緩存實體加載之前，事務數據不應該加載。

根據緩存的大小，您也可以考慮將這些值序列化到本地存儲。