實戰 .Net 資料訪問層 - 18

訪問|資料 談了些實現問題，來說說幾個題外話：

（1） 效能問題：Cache Management能顯著提高資料訪問效率，但對記憶體的要求比較高，尤其是在Web Application或Remoting Server這種應用環境下！

所以，這就要求我們應該將“錢”用在“刀刃”上（對記憶體毫不在乎者除外J），不能亂花錢！

一般，對於系統資料（如：應用 / 模組，組 / 使用者 / 許可權等）或Lookup Data（如：婚姻狀況列舉 / 政治面貌列舉等），可以考慮放入Cache；另外，如果客戶（請注意：不是開發人員！）認為變動可能性較小或頻率不高的Business Data也可以考慮放入Cache；

（2） 手工重新整理：Cache是把雙刃劍，帶來便利的同時也增添煩惱。“手工重新整理資料”可能就是其中最麻煩的事情！

在系統調試階段，我們還可以通過關閉Cache功能（在配

置資訊中注釋掉相關內容）來避免這個問題，可一旦上線，

就只能通過其它方式進行解決了！



在這裡，作者先試著給出3種解決方案：

i. 對於Web Application，可以利用.NET Framework提供的Dependency機制將Cache綁定至檔案系統，一旦資料變化，只需更新相關檔案或目錄資訊即可達到Cache Refresh目的（不符合Ease of Use標準L）！但對於Windows Application，Dependency就需要自己實現了L

ii. 可以使用Observer Pattern將所有的Data Access Logic更新操作進行登記，一旦調用更新方法，立刻執行相關delegate以更新Cache Data！

這或許是一個對客戶最為友好的解決方案（有個限制

條件：客戶不能直接修改Database資料J），但對開

發人員卻是一個無盡的“折磨”（整天提心弔膽，總

擔心忘了登記L）！

iii. 自己實現一個UI，對Cache Data進行Refresh Management！這是個介於上面兩種方法間的折衷方案，也是作者比較傾向的一種思路（當然了，如果哪位朋友有興趣將上面3種統統實現並有機整合之，那就功德無量了J）。





最後，奉上作者機器上的Cache部分配置資訊供各位參考：

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

<dafConfiguration>

<dal>

<class name="CustomerDal_ORM">

<method name="GetAllCustomers"

DistributionType="REMOTING"

cacheitem="allcustomers" />

</class>

</dal>

<cache>

<group name="business">

<item name="allcustomers">

<webapp absoluteExpiration="12.0,hour"

priority="High" />

<winapp accessCount="2" />

</item>

</group>

</cache>

</dafConfiguration>

</configuration>































































下一段：http://www.csdn.net/develop/Read_Article.asp?id=27562