.NET 缓存模块设计实践
上一篇谈了我对缓存的概念，框架上的理解和看法，这篇承接上篇讲讲我自己的缓存模块设计实践。
基本的缓存模块设计
最基础的缓存模块一定有一个统一的CacheHelper，如下:
publicinterfaceICacheHelper
{
TGet<T>(stringkey);
voidSet<T>(stringkey,Tvalue);
voidRemove(stringkey);
}
然后业务层是这样调用的
publicUserGet(intid)
{
if(id<=0)
thrownewArgumentNullException("id");
varkey=string.Format(USER_CACHE_KEY,id);
varuser=_cacheHelper.Get<User>(key);
if(user!=null)
returnuser;
return_repository.Get(id);
}
上面的代码没什么错误，但是实际运用的时候就产生疑问了，因为我一直强调缓存要保存"热数据"，那样"热数据"一定会有过期的时候，我们不可能另外写一个去Set。所以干脆就结合到一起写是比较合适的。
publicUserGetV2(intid)
{
if(id<=0)
thrownewArgumentNullException("id");
varkey=string.Format(USER_CACHE_KEY,id);
varuser=_cacheHelper.Get<User>(key);
if(user!=null)
returnuser;
user=_repository.Get(id);
if(user!=null)
_cacheHelper.Set(key,user);
returnuser;
}
上面的代码其实只是加了一个Set而已，就这样的设计的话，每次一个Get需要的重复代码实在是太多了，那么是不是应该更精简？这时候吃点C#语法糖就很有必要了，语法糖偶尔吃点增进效率，何乐而不为？
publicUserGetV3(intid)
{
if(id<=0)
thrownewArgumentNullException("id");
varkey=string.Format(USER_CACHE_KEY,id);
return_cacheHelperV2.Get<User>(key,()=>_repository.Get(id));
}
//ICacheGet<T>实现
publicTGet<T>(stringkey,Func<T>fetch=null)
{
Tresult=default(T);
varobj=Cache.Get(key);
if(objisT)
{
result=(T)obj;
}
if(result==null)
{
result=fetch();
if(result!=null)
Set(key,result);
}
returnresult;
}
这里我直接把Set方法都包装进了ICache.Get<T>，附带上FetchFunc。这样就把公共的操作抽象到了一起，简化了Cache的调用，完美的符合了我的想法。
缓存模块设计进阶
上一节里的ICacheV3几乎已经最精简了，但是其实参考了ServiceStack.Redis之后，我发现了更加的抽象方式。很明显上一节的所有代码里，都是手动管理Key的，对于通常的对象Cache，这个Key还需要手动吗?来上最后一份改进。
publicTGet<T>(objectid,Func<T>fetch=null)
{
vartype=typeof(T);
varkey=string.Format("urn:{1}:{2}",type.Name,id.ToString());//这里是关键，直接用TypeName来充当Key
returnGet(key,fetch);
}
publicTGet<T>(stringkey,Func<T>fetch=null)
{
Tresult=default(T);
varobj=Cache.Get(key);
if(objisT)
{
result=(T)obj;
}
if(result==null)
{
result=fetch();
if(result!=null)
Set(key,result);
}
returnresult;
}
Get方法完全自动化管理了Key，然后调用的方式再次被精简。
publicUserGetV4(intid)
{
if(id<=0)
thrownewArgumentNullException("id");
return_cacheHelperV3.Get<User>(id,()=>_repository.Get(id));
}
很明显还少了最重要的Set啊，Set的时候这个Key获取就要费一点事情了，最需要解决的是如何获取这个主键id的值。
publicclassUser
{
[PrimaryKey]//这个Attribute是最重要的东西
publicintUserId{get;set;}
publicstringUserName{get;set;}
publicstringCellphone{get;set;}
}
publicvoidSet<T>(Tobj)
{
//此处应该被缓存以提高反射的效率
vartype=typeof(T);
varprimaryKey=type.GetProperties()
.FirstOrDefault(t=>t.GetCustomAttributes(false)
.Any(c=>cisPrimaryKeyAttribute));//这里通过取PrimaryKeyAttribute来获取ID的value
varkeyValue=primaryKey.GetValue(obj,null);
varkey=string.Format("urn:{0}:{1}",type.Name,keyValue);
vardt=DateTime.UtcNow.AddDays(1);//假设默认缓存1天
varoffset=newDateTimeOffset(dt);
Cache.Set(key,obj,offset);
}
到这里，我想到的最终版本的ICache就完成了。这里还需要说明的是其实PrimaryKey可以更加灵活多变。很多时候一个Object的PrimaryKey是很复杂的，这时候设计Cache实体的时候可以变通下：
publicclassUserCacheEntity
{
[PrimaryKey]
publicintID
{
get
{
returnstring.Format("{0}:{1}",UserId,UserName);
}
}
publicintUserId{get;set;}
publicstringUserName{get;set;}
publicstringCellphone{get;set;}
}
上面的方式几乎可以自动管理常见的数据Cache了，唯一麻烦的是需要自定义一个CacheObject，这样就带来了实体转换的麻烦，这时候就要看怎么取舍了。
再次说明下我想要的ICache设计：
1.永远只Cache热数据，这意味着每个Key都要有过期时间
2.ICache自动管理Get/Set，最好能自动管理Key。
3.ICache精简同时又不失灵活。
详细的代码Demo可以参考：Git
更灵活的实现
我在写这篇总结之前，也一直在思考Cache应该放到什么层，普通三层的时候放哪里？DDD那样分层的时候又放哪里。Google了下，看到了一些参考。
http://stackoverflow.com/questions/15340173/in-which-layer-implement-the-cache
我觉得这里比较符合我的想法，Cache应该是全局任意的，当然实现起来当然是interface+IOC，这样引用起来更加的独立一些。
另外还有Cache更加高级的使用，AOP结合ICacheV4这样的设计，岂不是更好？这里我还没有去实现AOP的Attribute，这又是一个大话题的，下次再来实现吧。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持毛票票。