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