【渐进】延迟加载机制的简易实现（上）

      我们在软件设计中常遇到这样一种场景，一个对象的某个成员，它的加载很耗时，然而又不是总是需要，因为我们不希望它在对象初始化的时候就被加载，而是在它被显示使用时才去加载。

      我们总是建议暴露属性而不是成员，作用之一便是本文的主题"延迟加载", 属性的get,set使得我们能够主动的控制成员的加载。

      

1. public class Test
2. {
3.     private string _property;
4.  
5.     public string Property
6.     {
7.         get { return this._property; }
8.         set { this._property = value; }
9.     }
10. }

      以上就是最基本的属性写法，.net3.0之后，给了如下的语法糖：

1. public string Property { get; set; }

      然而很多时候，情况远远要复杂的多，于是有了如下的实现：

1. private object _property;
2.  
3.         public object Property
4.         {
5.             get
6.             {
7.                 if (this._property == null)
8.                     this._property = new object();
9.                 return this._property;
10.             }
11.         }

      当一个对象足够变得复杂后，上述代码更加使得代码臃肿而充斥大量重复的判断。作为程序员的我们总是有那么一股意识，把重复的抽取出来。于是我们隐约有了一个想法，是不是可以设计一个自动的延迟加载机制来代替这种写法？判断是重复的，实际的加载方法也是早已存在的，那么这个机制要做的就是自动的为对象加载某个成员的数据，而无需去重复的编码判断是不是已经加载或是未被加载。

      熟悉ORM的朋友对于延迟加载一定不陌生，多数ORM框架均提供了优秀的延迟加载机制。

      

1. [ActiveRecord("C_Article")]
2. public class Article : ActiveRecordBase<Article>
3. {
4.     [HasMany(typeof(Tag), Lazy = true)]
5.     public IList TagList { get; set; }
6. }

     

1. using (new SessionScope())
2. {
3.     Article article = Article.Find(1);
4.     Response.Write(article.TagList.Count);
5. }

 

     上述代码利用Castel的ActiveRecord框架展示了一个延迟加载的调用方式：一个特性（HasMany），一个范围声明（SessionScope），就完成了加载，这就是本文将尝试的设计。本文将先尝试以较简易的方式实现以便它可以立刻开始工作，后续篇幅将逐步完善这个设计。

      设计之前，先确定一下将要设计的机制的大致使用：不使用代理，AOP等思想对原有类做拦截,不引入特性做为标记，当用户需要使用延迟加载的属性时，需在当前代码上下文声明一个非延迟加载区域，形如SessionScope。

      首先，这里所设计的机制不同于ORM框架，这里的数据并非源于数据库，所以将由用户来实现正常的数据加载接口：

      

1. /// <summary>
2. /// 加载接口
3. /// </summary>
4. /// <typeparam name="TOut">加载的类型</typeparam>
5. /// <typeparam name="TIn">启用此加载的对载类型</typeparam>
6. public interface ILoader<TOut, TIn>
7. {
8.     /// <summary>
9.     /// 正常加载
10.     /// </summary>
11.     /// <param name="t"></param>
12.     /// <returns></returns>
13.     TOut Load(TIn t);
14. }

      用户需要实现如上接口来完成正常的数据加载。

      接下来，需要设计一个非延迟加载区域 NotLazyScope：

      

1. /// <summary>
2. /// 延迟加载区域
3. /// </summary>
4. public class NotLazyScope : IDisposable
5. {
6.     /// <summary>
7.     /// 延迟标记槽
8.     /// </summary>
9.     private LocalDataStoreSlot _slot;
10.     /// <summary>
11.     /// 延迟标记槽名称
12.     /// </summary>
13.     public static readonly string SLOT_NAME = "NotLazy";
14.     /// <summary>
15.     /// 声明延迟加载区域
16.     /// </summary>
17.     public NotLazyScope()
18.     {
19.         this._slot = Thread.GetNamedDataSlot(SLOT_NAME);
20.         Thread.SetData(this._slot, true);
21.     }
22.     /// <summary>
23.     /// 结束?延?加?区域声明
24.     /// </summary>
25.     public void End()
26.     {
27.         Thread.SetData(this._slot, false);
28.     }
29.  
30.     #region IDisposable 成员
31.  
32.     void IDisposable.Dispose()
33.     {
34.         this.End();
35.     }
36.  
37.     #endregion
38. }

      为了实现如SessionScope的语法声明方式，我们需要在当前的上下文记录一些标记，这里利用了线程栈的数据槽来实现。

      接着要设计主要的加载器，作为这个机制的调用入口：

     

1. /// <summary>
2. /// 一级缓存容器
3. /// </summary>
4. internal class PrimaryCache : Dictionary<object, Dictionary<string, object>> { }

 

      以上将作为一个缓存容器，后面会发掘出其他用途。

      

1. /// <summary>
2. /// 延?加?器
3. /// </summary>
4. public class LazyLoader
5. {
6.     /// <summary>
7.     /// 一级缓存
8.     /// </summary>
9.     private static PrimaryCache _pool = new PrimaryCache();
10.     /// <summary>
11.     /// 执?延?加?
12.     /// ?声明了NotLazyScope?在声明有效?围内将执??延?加?
13.     /// </summary>
14.     /// <typeparam name="TIn">执?加?的对?类型</typeparam>
15.     /// <typeparam name="TOut">加?的类型</typeparam>
16.     /// <param name="loader">加?所使用的接口实例</param>
17.     /// <param name="t">执?加?的对?实例</param>
18.     /// <param name="property">延?加?的属性名称</param>
19.     /// <returns>?回上一次加?结果</returns>
20.     public static TOut Load<TIn, TOut>(ILoader<TOut, TIn> loader, TIn t, string property)
21.         where TOut : class, new()
22.         where TIn : class, new()
23.     {
24.         if (Exist<TIn>(t, property))
25.             return _pool[t][property] as TOut;
26.  
27.         lock (_pool)
28.         {
29.             if (!Exist<TIn>(t, property))
30.             {
31.                 if (Lazy())
32.                     return default(TOut);
33.  
34.                 TOut result = loader.Load(t);
35.  
36.                 if (!_pool.ContainsKey(t))
37.                     _pool.Add(t, new Dictionary<string, object>());
38.                 _pool[t].Add(property, result);
39.             }
40.         }
41.  
42.         return Lazy() ? default(TOut) : loader.Load(t);
43.     }
44.     /// <summary>
45.     /// 是否存在缓存
46.     /// </summary>
47.     /// <typeparam name="T"></typeparam>
48.     /// <param name="t"></param>
49.     /// <param name="property"></param>
50.     /// <returns></returns>
51.     private static bool Exist<TIn>(TIn t, string property)
52.     {
53.         return _pool.ContainsKey(t) && _pool[t].ContainsKey(property);
54.     }
55.     /// <summary>
56.     /// 是否延?
57.     /// </summary>
58.     /// <returns></returns>
59.     private static bool Lazy()
60.     {
61.         return !Convert.ToBoolean(Thread.GetData(Thread.GetNamedDataSlot(NotLazyScope.SLOT_NAME)));
62.     }
63. }

      完成了以上这些就足够完成本文的设计了。

      要想真正使用，还需要先来实现一个ILoader接口：

      

1. /// <summary>
2. /// 好友加?器
3. /// </summary>
4. internal class UserFriendLoader : ILoader<List<long>, UserInfoEN>
5. {
6.  
7.     #region ILoader<List<long>,UserInfoEN> 成员
8.  
9.     public List<long> Load(UserInfoEN t)
10.     {
11.         return UserBO.GetFriendUserIdList(t.UserId);
12.     }
13.  
14.     #endregion
15. }

      现在可以来尝试使用它了：     

     

1. return Lazy.LazyLoader.Load<UserInfoEN, List<long>>(new Lazy.UserFriendLoader(), this, "FriendUserIdList");

 

     

1. using (new Lazy.NotLazyScope())
2. {
3.     //...
4. }

 

    

     上面的代码完成了这个简易设计，能方便的让你在现有项目中引入这个机制而不用做大幅度改动。不过对于上述设计所提供的调用，可能会让您觉得使用起来比较麻烦，或许您更倾向于简单的使用类似特性的语法对属性进行延迟加载的声明，在接下来的篇幅将一步步尝试对设计进行改造，让它的调用更友好，设计更合理。

     

      从延迟机制的实现衍生：您可能会注意到上述实现中，对于延迟加载的属性，当实际加载被执行一次后，便无需再次执行就直接从缓存中获得，基于此可衍生出一个缓存机制，如果您熟悉NHibernate，想必会联想到NH的多级缓存设计，对了，这里便暗合了这种设计，只不过现在这个机制不是基于数据库了，从这个缓存出发，便可扩展出延迟加载机制的一级缓存。

 

转载于:https://www.cnblogs.com/wsky/archive/2009/10/23/1588890.html