2009-10-28 27 views
1

我們正在考慮在應用程序中進行一些架構更改,這可能會影響我們將作爲這些更改結果使用的技術。緩存數據並通知客戶有關ASP.NET中數據的更改

說,我指在這個崗位的變化是這樣的:

我們發現,我們的應用程序的某些部分有共同的數據和共同事務,所以我們提取的成GlobalServices服務,與它自己的主數據庫。 現在,這個服務可能會有自己的緩存,這樣它就不必在每次調用時從數據庫中檢索數據。 因此,當一個客戶打電話給那個更新數據的服務時,其他客戶可能對這個改變感興趣,或者不是。現在取決於我們是否決定在客戶端保留一個緩存。

這意味着如果客戶端將擁有自己的本地緩存,他們將不得不以某種方式得到通知(並首先註冊通知)。否則,他們將始終從GlobalServices服務獲取數據。

我需要在這裏你受過教育的意見傢伙:

1) Is it a good idea to keep a local cache on the clients to begin with? 
2) If we do decide to keep a local cache on the clients, would you use 
    SqlCacheDependency to notify the clients, or would you use WCF for 
    notifications (each might have its cons and pros) 

感謝很多人,

阿維

回答

0

我喜歡你的SqlCacheDependency的聲音,但我會回答這個問題從不同的角度因爲我曾與一個團隊合作過類似的情況。我們創建了一個master數據庫,並使用觸發器來創建主數據中正在更改的數據的XML表示,並將其存儲在TransactionQueue表中,其中包含一些有關更改內容,何時更改以及誰更改內容的元數據。客戶端數據庫會定期檢查隊列中感興趣的項目,並根據需要處理XML並更新它自己的表格。

我們也對客戶端進行了相同的更新,以更新主服務器。我們在客戶端數據庫上設置觸發器和一個TransactionQueue表來將數據發送回主服務器。這反過來會在下次輪詢時更新所有其他客戶端數據庫。

這樣做的好處在於,它在客戶端平臺和客戶端數據結構上相當不可知,所以我們能夠在一系列傳統和第三方系統上使用該方法。這裏的另一個重點是你可以從循環中取出任何數據庫(包括主數據庫 - 例如連接失敗),其他數據庫仍然可以正常工作。由於我們的主數據庫位於我們公司的防火牆之後,因此這對我們非常有效,並且更簡單的Web數據庫與我們的ISP一起坐着。

這種方法顯然有缺點,就像種族危害一樣,所以我們對事務處理,錯誤處理,去重等順序都非常小心。我們還構建了一個管理GUI,在重要數據之前提供人工交互層在主人被改變了。

祝你好運! Tim

+0

好吧,這聽起來很有趣,也很複雜,只有dba才能提供的解決方案:)恐怕我們在這個剛起步的公司沒有這方面的知識。我個人不喜歡把太多的邏輯放入數據庫。 但是,如果它對你有效,那麼這很好,而且很高興知道這樣的工作方式。 謝謝蒂姆! – 2009-10-28 14:17:30