|
GetCache的代碼很簡單：有則取之，無則填之，“是否過期”是其有效性的唯一判斷條件！接下來，作者就這個“是否過期”問題來進行一些探索，看看到底是怎么回事。
Ok，還是先請大家看段代碼：
代碼15：過期無效之Cache篇！
public class CacheManager
{
private bool IsCacheExpired(string key)
{
bool bExpired = false;
if (HttpContext.Current != null)
{
// Web cache自動支持thread-safe，無須鎖定資源
if (HttpContext.Current.Cache[key] == null)
bExpired = true;
}
else
{
// Windows cache是自己實現的，不確保thread-safe，必須鎖定資源
lock (_htWinAppCache)
{
if (_htWinAppCache[key] == null)
bExpired = true;
else
{
WinAppCache cache = (WinAppCache)
_htWinAppCache[key];
if (cache.IsExpired())
{
cache = null;
_htWinAppCache[key] = null;
bExpired = true;
}
}
}
}
return bExpired;
}
}
各位，從上面的代碼中，是否看出了一些端倪？
由于Web Appliction Cache（通過HttpContext.Current != null判斷是否Web ApplicationJ）得到了.NET Framework的直接支持，所以判斷“是否過期”非常方便，也不存在任何thread-safe問題J。但這個問題對于Windows Application來說就不太美妙了，既要自己實現IsExpired，又要擔心多線程并發訪問時的種種問題，真是吃力不討好的苦差啊L！上面代碼中的“_htWinAppCache”（自定義Cache）以及“lock (_htWinAppCache)”（確保thread-safe）就是為了應付Windows Application而采取的兩種非常手段！
可能有朋友會問了，Windows Application也要考慮Cache Management問題嗎？我的回答是：看情況而定！
對于普通的Client Windows Application，確實很少（請注意：不是沒有）涉及這個話題，但對于Server Application，例如：Remoting Server，Windows Service（WebServices不在此列），都促使我們不得不面對“嚴峻的現實”L（.NET Framework怎么就沒有提供System.Windows.Caching命名空間呢？害得我們不得不另起爐灶L）！
上面的代碼就是考慮到Web Application與Windows Application并存的情況下，我們該如何實現Cache Management支持！
當前版本中，作者實現Windows Application下的“是否過期”非常簡單：就是看它被訪問過幾次！而這個次數，當然必須在配置信息中進行設定了（請參考本段最后的一個配置樣例）！
Web Application中的Cache Management自動化程度雖然很高，但也“逃不過”配置一關，而讀取完配置信息后的處理工作就當仁不讓地落到了Parameter Classes的肩上（請參考上面的Cache Management之“結構示意圖”）！
下一段：http://www.csdn.net/develop/Read_Article.asp?id=27561
| 
