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