上一篇談了我對緩存的概念,框架上的理解和看法,這篇承接上篇講講我自己的緩存模塊設計實踐。
基本的緩存模塊設計
最基礎的緩存模塊一定有一個統一的CacheHelper,如下:
public interface ICacheHelper { T Get<T>(string key); void Set<T>(string key, T value); void Remove(string key); }
然後業務層是這樣調用的
public User Get(int id) { if (id <= 0) throw new ArgumentNullException("id"); var key = string.Format(USER_CACHE_KEY, id); var user = _cacheHelper.Get<User>(key); if (user != null) return user; return _repository.Get(id); }
上面的代碼沒什麼錯誤,但是實際運用的時候就產生疑問了,因為我一直強調緩存要保存"熱數據",那樣"熱數據"一定會有過期的時候,我們不可能另外寫一個去Set。所以干脆就結合到一起寫是比較合適的。
public User GetV2(int id) { if (id <= 0) throw new ArgumentNullException("id"); var key = string.Format(USER_CACHE_KEY, id); var user = _cacheHelper.Get<User>(key); if (user != null) return user; user = _repository.Get(id); if (user != null) _cacheHelper.Set(key, user); return user; }
上面的代碼其實只是加了一個Set而已,就這樣的設計的話,每次一個Get需要的重復代碼實在是太多了,那麼是不是應該更精簡?這時候吃點C#語法糖就很有必要了,語法糖偶爾吃點增進效率,何樂而不為?
public User GetV3(int id) { if (id <= 0) throw new ArgumentNullException("id"); var key = string.Format(USER_CACHE_KEY, id); return _cacheHelperV2.Get<User>(key, () => _repository.Get(id)); } //ICache Get<T>實現 public T Get<T>(string key, Func<T> fetch = null) { T result = default(T); var obj = Cache.Get(key); if (obj is T) { result = (T)obj; } if(result == null) { result = fetch(); if (result != null) Set(key, result); } return result; }
這裡我直接把Set方法都包裝進了ICache.Get<T>,附帶上Fetch Func。這樣就把公共的操作抽象到了一起,簡化了Cache的調用,完美的符合了我的想法。
緩存模塊設計進階
上一節裡的ICache V3幾乎已經最精簡了,但是其實參考了ServiceStack.Redis之後,我發現了更加的抽象方式。很明顯上一節的所有代碼裡,都是手動管理Key的,對於通常的對象Cache,這個Key還需要手動嗎?來上最後一份改進。
public T Get<T>(object id, Func<T> fetch = null) { var type = typeof(T); var key = string.Format("urn:{1}:{2}", type.Name, id.ToString());//這裡是關鍵,直接用TypeName來充當Key return Get(key, fetch); } public T Get<T>(string key, Func<T> fetch = null) { T result = default(T); var obj = Cache.Get(key); if (obj is T) { result = (T)obj; } if (result == null) { result = fetch(); if (result != null) Set(key, result); } return result; }
Get方法完全自動化管理了Key,然後調用的方式再次被精簡。
public User GetV4(int id) { if (id <= 0) throw new ArgumentNullException("id"); return _cacheHelperV3.Get<User>(id, () => _repository.Get(id)); }
很明顯還少了最重要的Set啊,Set的時候這個Key獲取就要費一點事情了,最需要 解決的是如何獲取這個主鍵id的值。
public class User { [PrimaryKey] //這個Attribute是最重要的東西 public int UserId { get; set;} public string UserName { get; set; } public string Cellphone { get; set; } } public void Set<T>(T obj) { //此處應該被緩存以提高反射的效率 var type = typeof(T); var primaryKey = type.GetProperties() .FirstOrDefault(t => t.GetCustomAttributes(false) .Any(c => c is PrimaryKeyAttribute));//這裡通過取PrimaryKeyAttribute來獲取ID的value var keyValue = primaryKey.GetValue(obj, null); var key = string.Format("urn:{0}:{1}", type.Name, keyValue); var dt = DateTime.UtcNow.AddDays(1);//假設默認緩存1天 var offset = new DateTimeOffset(dt); Cache.Set(key, obj, offset); }
到這裡,我想到的最終版本的ICache就完成了。這裡還需要說明的是其實PrimaryKey可以更加靈活多變。很多時候一個Object的PrimaryKey是很復雜的,這時候設計Cache實體的時候可以變通下:
public class UserCacheEntity { [PrimaryKey] public int ID { get { return string.Format("{0}:{1}", UserId, UserName); } } public int UserId { get; set; } public string UserName { get; set; } public string Cellphone { 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結合ICache V4這樣的設計,豈不是更好?這裡我還沒有去實現AOP的Attribute,這又是一個大話題的,下次再來實現吧。
以上就是本文的全部內容,希望對大家的學習有所幫助,也希望大家多多支持腳本之家。