博客园-zhuweisky

ESBasic 可复用的.NET类库（20）－－ TopN排行榜容器 TopNOrderedContainer

zhuweisky — Mon, 18 Jan 2010 02:00:00 GMT

阅读: 1411 评论: 3 作者: zhuweisky 发表于 2010-01-18 10:00 原文链接

1.缘起：

假设我们的会员管理系统有一个排行榜的功能，需要每隔一段时间就对系统中的所有会员（假设会员数有100万）的积分进行排序，然后对其中的前100名进行某些奖励。

这是一个典型的TopN算法――对巨大数量的对象进行排序，然后只需要取出最Top的前N名（N比对象总数小很多），作为排行榜的数据。

解决这样的问题，我们要注意一点，如果我们每次都对所有的对象进行完全排序，那无疑效率非常低下，而且非常不划算。因为我们只需要前N名，而不是所有对象的先后顺序。

我设计了ESBasic.ObjectManagement.TopNOrderedContainer来解决排行榜算法，TopNOrderedContainer只将资源花费在真正需要计算的地方，另外，TopNOrderedContainer支持在运行过程中，将不断新产生的对象加入到排行榜。

2.适用场合：

TopNOrderedContainer用于对巨大数量的对象进行TopN排序。其适用场合有如下特点：

（1）需要被排序的对象的数量非常巨大（如几百万、甚至几千万）。

（2）对系统有价值的排序结果只有前N名。

（3）N远小于总的对象数量。

3．设计思想与实现

TopNOrderedContainer的排行榜算法的思路是这样的，使用一个长度为N的数组，来存放最Top的N个对象，越Top的对象其在数组中的Index就越小。这样，每次加入一个对象时：

（1）首先，判断当前的排行榜的最后一名是否比新加入的对象更Top，如果是则丢弃它。

（2）其次，看新加入的对象是否比当前排行榜的第一名更Top，如果是，则新的对象应该被放置在index为0的位置。

（3）否则，就采用二分查找算法为新加入的对象找到合适的位置，并调整排行榜中位于插入位置后面的对象的位置。

当然，在具体实现的源码中，我们看到了还有一些边界条件的处理这里没描述出来。

TopNOrderedContainer的类图如下所示：

我们看到TopNOrderedContainer有一个泛型参数TObj，它是进行排序的对象的类型。TObj的泛型约束表明TObj必须实现IOrdered接口。IOrdered接口定义如下：

    ///

    /// IOrdered 参与排行榜排序的对象必须实现的接口。
    ///

    /// 参与排行榜排序的对象的类型
    public interface IOrdered<TOrderedObj>
    {
        bool IsTopThan(TOrderedObj other);
    }

关于这个接口要注意两点：

第一，该接口的唯一方法的名字为什么不是类似IsGreaterThan、IsSmallerThan等，而是IsTopThan？因为不同的应用有不同的需求，有的可能是要选择前N个最大的，有的是要选择前N个最小的，甚至有的可能选择前N个最著名的，等等。而IsTopThan可以覆盖所有这些情况，反正都是最Top的N个嘛。

第二，IOrdered接口之所以使用泛型参数TOrderedObj，是为了避免派生类在实现IsTopThan方法时，需要将参数other的类型进行向下转换。

现在我们在回到TopNOrderedContainer，关于其实现要注意以下几点：

（1）排行榜容器可以在多线程的环境中使用。TopNOrderedContainer使用SmartRWLocker来对Add方法进行同步，之所以选择读写锁而不是简单的lock，是因为使排行榜容器在应对多读/少写的状况时能支持更大的并发。

（2）排行榜的生成采用的是插入排序策略，排序的具体算法是二分查找排序。Adjust方法的实现就是二分查找算法的体现。

（3）GetTopN方法用于返回当前的排行榜的拷贝。之所以返回一个拷贝，是因为外部对返回的数组进行任何操作都不会影响到TopNOrderedContainer的内部集合。

（4）为何不将TopN排序直接实现为一个静态方法？如果以静态的方式实现，那我们就没有办法继续动态的Add新的对象进入排行榜，即使要达到这样的目的，也就只有构造新的list，再次调用static GetTopN方法，如此就浪费了前面的计算成果。

4. 使用时的注意事项

如果要排序的对象的数量与TopN的N值的差距并不大，那么使用TopNOrderedContainer并不一定是最佳的选择，这时我们可以采用一些高效的完全排序算法对所有的对象进行排序，然后再取出前N名，可能速度会更快。

　　当然，我们也可以使用最大最小堆的算法来实现TopN的排序，也是完全可行的。

5.扩展

TopN排行榜容器TopNOrderedContainer暂时没有任何扩展。

注：ESBasic源码可到http://esbasic.codeplex.com/下载。
ESBasic讨论QQ群：37677395
ESBasic开源前言

评论: 3　查看评论　发表评论

最新新闻：
· 美调查公司称苹果iPad配件成本最低219美元(2010-02-10 17:20)
· 摩尔庄园：儿童生意密码(2010-02-10 17:15)
· Facebook与美国在线合作整合AIM动态功能(2010-02-10 16:41)
· NDepend 3.0已与Visual Studio集成(2010-02-10 16:17)
· Ruby in Steel 1.5发布，去除IronRuby支持(2010-02-10 16:14)

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

ESBasic 可复用的.NET类库（19）－－热缓存 IHotCache

zhuweisky — Tue, 05 Jan 2010 02:13:00 GMT

阅读: 1621 评论: 5 作者: zhuweisky 发表于 2010-01-05 10:13 原文链接

1.缘起：

假设我们有一个订单系统，现在这个系统要增加一个功能――允许客人查核他认为有问题的订单的详细信息。当客人觉得自己的某个订单不对劲时，他首先会从订单系统查询这个订单的详细信息，然后打电话告诉我们的客服有问题的订单的编号，客服再去查核，如果属实，客服还要进一步上报，如果该订单非常重要，则可能需要更进一步上报复查等。

从这个需求我们看到，同一个订单可能会在比较短的时间内查询数次甚至数十次，所以我们可以称这个订单为“热点”订单。而其它的成千上万的订单可能在一个月内都不被查询一次。

我设计热缓存ESBasic.ObjectManagement.Cache. IHotCache就是缓存类似“热点”订单的这些对象。

热缓存的形象示意图如下：

2.适用场合：

根据上述的描述，我们可以总结一下热缓存IHotCache的使用场合：

（1）根据我们系统的需求，目标对象群中的某些对象的“热”的程度可以明显地与其它对象区分开来。

（2）加载某一类型的对象到我们的系统中需要花费比较大的气力（比如加载速度很慢、加载过程很繁琐），而且一旦加载就会被经常使用。

（3）在指定的时间周期内不被访问的对象可以被卸载掉。如果一个“热”对象变“冷”了，那么我们就可以将其从热缓存中移除。

（4）当然，要被缓存的对象必须有唯一的ID。

3．设计思想与实现

IHotCache的接口定义如下：

///

/// IHotCache 用于缓存那些活跃的对象，并定时删除不活跃的对象。该接口的实现必须是线程安全的。
///

    public interface IHotCache<TKey, TObject> where TObject : class
    {
        ///

/// DetectSpanInSecs 多长时间检测一次对象是否活跃，单位：秒。
///

int DetectSpanInSecs { set; }

///

        /// MaxMuteSpanInMinutes 对象最大的沉默时间（分钟）。如果一个对象在MaxMuteSpanInMinutes时间间隔内都不被访问，则将被从缓存中清除。
        /// 如果该属性的值被设置为小于或等于0，则表示永远不会从缓存中清除。
        ///

int MaxMuteSpanInMinutes { set; }

///

/// MaxCachedCount 最多缓存的对象个数。当超过此个数时，不再缓存新的对象。
///

        int MaxCachedCount { get; set; }

        IObjectRetriever<TKey, TObject> ObjectRetriever { set; }
        int Count { get; }
        long RequestCount { get; } //请求次数
        long HitCount { get; }//命中的次数
        DateTime LastReadTime { get; }

        void Initialize();
        void Clear();
        void Add(TKey id, TObject obj);
        void Remove(TKey id);

        ///

/// Get 如果缓存中存在目标则直接返回，否则通过ObjectRetriever提取对象并缓存。
///

        TObject Get(TKey id);

        IList<TObject> GetAll();

        event CbSimple CacheContentChanged;
    }

注意这个接口的泛型参数TObject有一个泛型约束，其表明TObject必须是一个引用类型，这表示我们不能使用热缓存来缓存那些值类型的对象。

当你向IHotCache请求一个对象时，如果对象不在热缓存中（有可能是从来还未加载进缓存，也有可能是因为对象变“冷”后被移除缓存了），则会加载该对象到热缓存中并返回。我们是借助前面介绍的对象获取器IObjectRetriever来获取目标对象的。

热缓存会每隔一段时间检测一次缓存中的对象是否已经变“冷”――即在MaxMuteSpanInMinutes时间段内都没有被访问过。这个定时检测就是使用循环引擎AgileCycleEngine来做到的。如果一个对象已经变“冷”，则会将其移除热缓存――热缓存只缓存那些“热”的东西，所以放“冷”了的就必须把它移除掉。

RequestCount和HitCount分别表示热缓存接收到的请求对象的次数，和缓存命中的次数――即无需IObjectRetriever加载而直接从缓存中返回对象的次数。这两个属性提供一些统计数据，以反映我们当前使用热缓存的价值究竟有多大，以此我们可以判断这个地方是否真的需要使用热缓存。

关于HotCache的具体实现，还需要注意以下几个方面：

（1）为了允许在多线程的环境中使用热缓存，所以HotCache必须在对内部的dictionary操作的时候进行加锁控制。

（2）热缓存在初始化（Initialize方法）时，启动循环引擎来定时检测缓存的每个对象的冷热程度。

（3）使用CachePackage类来封装每个被缓存的对象，其中主要是记录了被封装对象的最后一次访问时间。

（4）如果缓存中不存在目标对象、IObjectRetriever也加载不到目标对象，Get方法将返回null。

4. 使用时的注意事项

（1）有两种方式可以将对象添加到热缓存中，一种是热缓存借助IObjectRetriever自动加载对象；另一种是通过调用其Add方法加入。如果我们已经预计到某个对象是“热”对象，那么就可以先将其Add到热缓存中以备用。特别是，当IObjectRetriever获取这个对象比较费气力时：）。

（2）热缓存加速了对“热”对象的访问，但是这是以占用内存为代价的。如果你的对象访问比较平均，没有凸显出特别“热”的对象，那么使用热缓存的作用就不大了。

（3）当你确定不会再使用某个对象时，可以立即调用Remove方法将其从热缓存中手动移除，而不是等到其变“冷”后才被热缓存自动移除。当这样的对象比较多，而且对象比较大时，这样做可以立即释放比较大的内存空间。

（4）如果某个对象已经被判定为无效或者已被外界修改（缓存中的对象的数据已经是老版本），则可以调用Remove方法将其从热缓存中移除。

（5）MaxMuteSpanInMinutes属性设置为多少比较合适，取决于你的具体应用，也许是10分钟，也有可能是24小时。如果这个属性和DetectSpanInSecs属性、MaxCachedCount属性能进行合理搭配设置，则可以使得热缓存的运行价值最大化。

5.扩展

热缓存IHotCache暂时没有任何扩展。

注：ESBasic源码可到http://esbasic.codeplex.com/下载。
ESBasic讨论QQ群：37677395
ESBasic开源前言

评论: 5　查看评论　发表评论

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

ESBasic 可复用的.NET类库（18）－－智能字典缓存 ISmartDictionaryCache

zhuweisky — Mon, 21 Dec 2009 08:38:00 GMT

阅读: 1735 评论: 4 作者: zhuweisky 发表于 2009-12-21 16:38 原文链接

1.缘起：

假设我们有一个会员管理系统，需要向各方提供查询会员基础资料的功能。会员一经注册，其基础资料就将不再发生变化（如会员帐号、身份证ID、注册时间等等）。

基于这样的需求，我们可以将会员的基础资料“永久地”缓存在内存中，从而提升对任何一个会员基础资料的查询速度。

我设计了ESBasic.ObjectManagement.Cache.ISmartDictionaryCache来对这种性质的对象进行缓存。

职能字典缓存的形象示意图如下：

2.适用场合：

在使用ISmartDictionaryCache之前，必须满足以下条件：

（1）将要被缓存的每个对象都有唯一的ID。

（2）被缓存的对象一旦“出生”就是恒定不变的。

（3）对象永远不会被销毁，或者说即使被销毁了在缓存中仍然存在也无关紧要。

3．设计思想与实现

ISmartDictionaryCache的接口定义如下：

    public interface ISmartDictionaryCache<Tkey ,TVal>
    {
        IObjectRetriever<Tkey, TVal> ObjectRetriever { set; }
        int Count { get; }

        void Initialize();

        ///

        /// Get 如果缓存中不存在id对应的object，则采用ObjectRetriever提取一次，如果仍然提取不到则返回null。
        ///

        TVal Get(Tkey id);

        void Clear();

        ///

        /// HaveContained 当前容器是否已经存在目标对象。
        ///

        bool HaveContained(Tkey id);

        IList<TVal> GetAllValListCopy();

        IList<Tkey> GetAllKeyListCopy();
    }

ISmartDictionaryCache依赖于我们前面介绍的IObjectRetriever接口，这就表示智能字典缓存是通过IObjectRetriever来将对象加载到缓存中来的。

Initialize方法执行时，会将所有对象都加载到内存中。

当外部调用Get方法时，如果目标对象在缓存中不存在，缓存则会调用IObjectRetriever加载目标对象。如果目标对象在持久化存储中都不存在，就会返回null。

注意，ISmartDictionaryCache并没有提供任何将对象移除缓存的方法，这表明对象一旦加载到缓存中，就将一直存在直到系统停止运行。

ISmartDictionaryCache接口的实现是简单的。同样的，SmartDictionaryCache可以在多线程的环境中使用，因为我们在实现时对内部集合ditionary进行了加锁控制。

4. 使用时的注意事项

（1）在使用智能字典缓存时，要考虑到对象的数量和对象的尺寸大小的问题。因为如果对象的数量巨大，而且对象的个头也很大，那将占用很多的内存空间。

（2）如果缓存中的对象被访问的概率不是一样的，而是由明显的差别，比如有绝大部分对象从来不被访问，有的对象被密集访问，那这个时候可以考虑使用我们后面即将介绍的“热缓存”IHotCache来代替智能字典缓存。

（3）智能字典缓存在初始化时调用了IObjectRetriever接口的RetrieveAll方法，但是正如我们在介绍IObjectRetriever时提到的，在实现IObjectRetriever接口的RetrieveAll方法，不一定要真正的返回所有的对象，你可以只返回那些你认为将会被使用到的对象。甚至，你可以返回一个不包含任何元素的集合，这样，智能字典缓存就只会缓存那些至少被访问过一次的对象了。在某些系统中，这也许可以有效地节省一些内存空间。

5.扩展

智能字典缓存ISmartDictionaryCache只能缓存恒定不变的对象？嗯，这一点是千真万确的。但是，有些情况我们可以灵活处理。

还是以我们在缘起部分提到的那个例子继续讲解，让我们在其基础上，再假设一个会员（Member）的绝大部分资料是在注册时就确定下来不会发生改变的，但是有小部分资料（比如对应这数据库中Member表中的几个列）是会发生变化的，比如会员的额度、密码、最后一次访问时间等这样的信息。当外部向系统请求这些非恒定信息时，我们就无法从智能字典缓存中获取了，因为智能字典缓存中的目标会员的这些字段可能已经不是正确的值了。

基于这样的情况，我们仍然是可以使用智能字典缓存的。这里我提出一个SubObject（“子对象”）的概念。所谓“子对象”就是由某对象的一部分属性构成的一个新的对象。

所以，我们可以将Member中恒定不变的部分抽出来形成一个子对象，如SubMember，那么SubMember就符合了使用ISmartDictionaryCache进行缓存条件。当外部要查询会员的基础资料属于恒定部分时，我们就可以非常快速地从ISmartDictionaryCache获取返回。

对于像Member这样由恒定部分和非恒定部分构成的对象来说，除了使用这种方式进行缓存之外，还有其它的办法。但由于超出了本节的主题，我们会在其它小节进行介绍。

注：ESBasic源码可到http://esbasic.codeplex.com/下载。
ESBasic讨论QQ群：37677395
ESBasic开源前言

评论: 4　查看评论　发表评论

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

ESBasic 可复用的.NET类库（17）－－对象获取器IObjectRetriever

zhuweisky — Thu, 10 Dec 2009 01:12:00 GMT

阅读: 1274 评论: 0 作者: zhuweisky 发表于 2009-12-10 09:12 原文链接

1.缘起：

ESBasic中许多管理对象的容器都用到了这个ESBasic.ObjectManagement.IObjectRetriever接口，所以单独将其提出来介绍一下。

当我们向对象容器（Container）请求某个对象时，也许目标对象还未加载到容器中，这可能是因为容器在初始化的时候就没有加载这个对象，也有可能是因为这个对象是容器初始化以后新增到数据库（当然也有可能是其它的持久化存储）的。在这种情况下，对象容器就可以借助IObjectRetriever来将目标对象从数据库等持久化存储中加载到容器中来。

通过IObjectRetriever接口，我们就将对象的加载与对象的管理两种不同的职能区分开来了。对象的加载往往是与具体的应用密切相关的，而对象的管理功能却可以被大规模复用。不同的应用只要实现IObjectRetriever接口，然后将其注入到要复用的对象容器中，就可以使用ESBasic提供的那些有用的对象管理容器了。

　　对象获取器与其它组件协作时的形象示意图如下：

2.适用场合：

在实现IObjectRetriever接口或使用与之相关的对象管理容器时，必须满足一个条件：每个对象都有唯一的一个ID。

3．设计思想与实现

IObjectRetriever的接口定义如下：

    public interface IObjectRetriever<Tkey ,TVal>
    {
        ///

/// Retrieve 根据ID获取目标对象。
///

TVal Retrieve(Tkey id);

///

/// RetrieveAll 获取所有的对象。
///

        IDictionary<Tkey, TVal> RetrieveAll();
    }

这个接口相当简单，其有两个泛型参数，TKey表示的是对象ID的类型，TVal就是对象自身的类型。而其中的两个方法，一个是根据ID从持久化存储中提取对象，一个则是提取所有的对象。

4. 使用时的注意事项

在实现IObjectRetriever接口时，可以有些灵活性：

（1）我们不是只能从数据库获取对象，也可以从文件获取，甚至是可以从网络获取，或者从其它的服务器获取，等等。

（2）实现RetrieveAll方法时，不一定真的要获取所有的对象。通常，RetrieveAll方法在容器初始化时使用，这时根据你应用的需求，只需要加载初始化时够用的对象就好了，因为有些对象可能在系统运行的整个生命周期内都用不上，那就没有必要加载它。甚至，你可以返回一个不包含任何元素的字典－－如果容器在初始化时，不需要加载任何对象的话。

　　另外，还有一个你需要考虑的是对象的数量，如果对象的数量巨大，而且全部都需要在初始化时加载到容器中，则可能导致初始化要很长的时间，而且也要占用很大的内存。所以，只加载那些真正需要用到的对象，即可加快初始化速度，也可以节省内存。

5.扩展

在设计和实现多叉树（ESBasic.ObjectManagement.Trees.Multiple.IMultiTree）时，我借助了IAgileNodePicker来提取多叉树中还未加载的节点。IAgileNodePicker继承自IObjectRetriever，并添加了一个获取多叉树根节点的PickupRoot方法。

在介绍多叉树的章节，我们会再详细介绍IAgileNodePicker这个接口。

注：ESBasic源码可到http://esbasic.codeplex.com/下载。
ESBasic讨论QQ群：37677395
ESBasic开源前言

评论: 0　查看评论　发表评论

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

ESBasic 可复用的.NET类库（16）－－定时刷新缓存管理器 IRefreshableCacheManager

zhuweisky — Sat, 21 Nov 2009 02:09:00 GMT

阅读: 1560 评论: 4 作者: zhuweisky 发表于 2009-11-21 10:09 原文链接

1.缘起：

为了提升系统的性能或减轻数据库的压力等原因，我们经常在系统中使用缓存来把那些经常使用的数据保留在内存中。如果因为某些原因，缓存中这些经常使用的数据不能及时与数据源进行同步更新，那么采用定时刷新缓存中的数据有可能就是一种合适的选择。

如果你的缓存是定时刷新，那么你就需要自己为其维护一个定时器或循环引擎。如果你的系统中像这样定时刷新的缓存有多个，而且每个缓存定时刷新的时间间隔又要求不一样，那么，使这些缓存按照你预想的情况进行运转，你就需要花费一些气力。

我设计了定时刷新缓存管理器IRefreshableCacheManager来帮助你管理你系统中所有需要进行定时刷新的缓存。它可以根据每个缓存的刷新时间间隔要求，在正确的时刻，刷新其所管理的缓存。你不用再自己手动去处理定时器或循环引擎，IRefreshableCacheManager自动为你完成这一切。

2.适用场合：

（1）系统中需要使用一个或多个需要进行定时刷新的缓存。

（2）每个缓存所要求的刷新时间间隔可能都不一样。

（3）刷新的时间间隔并不要求精确。

3．设计思想与实现

本节所讲述的是定时刷新缓存管理器IRefreshableCacheManager，其重点在于“管理器”，而不是在于“缓存”，这点是必须清楚的。缓存只是被管理器管理的对象。

能够被IRefreshableCacheManager管理的缓存必须是可定时刷新的缓存，也就是说，这些缓存必须实现IRefreshableCache接口以表明自己可以接受管理器的管理。IRefreshableCache定义如下：

    public interface IRefreshableCache
    {
        ///

/// RefreshSpanInSecs 定时刷新的时间间隔（秒）。如果设置为0，则表示与IRefreshableCacheManager的刷新时间统一。
///

int RefreshSpanInSecs { get; }

///

/// LastRefreshTime 最后一次刷新时间。
///

        DateTime LastRefreshTime { get; set; }

        void Refresh();
    }

这个接口相当简单，它只要求缓存提供Refresh方法进行刷新，并通过RefreshSpanInSecs属性表示出自己希望进行定时刷新的时间间隔。如果这个属性设置为0（默认值），则表示该缓存接受管理器的统一调度。

LastRefreshTime属性用于记录最后一次刷新结束的时间，该属性的值由管理器进行设置。

我们从IRefreshableCache接口的定义看到，管理器不用关心与缓存中的数据相关的任何信息，这是由具体的应用在实现IRefreshableCache接口时才指定的。

接下来，我们看看IRefreshableCacheManager接口的定义：

    public interface IRefreshableCacheManager
    {
        ///

/// RefreshSpanInSecs 定时刷新缓存的时间间隔。
///

        int RefreshSpanInSecs { set; }

        IList<IRefreshableCache> CacheList { set; }

        void Initialize();

        ///

/// RefreshNow 手动刷新被管理的所有缓存。
///

void RefreshNow();

///

/// AddCache 动态添加缓存。
///

        void AddCache(IRefreshableCache cache);

        ///

/// RemoveCache 动态移除缓存。
///

        void RemoveCache(IRefreshableCache cache);

        ///

/// CacheRefreshFailed 当某个缓存刷新抛出异常时，将触发该事件。
///

event CbCacheException CacheRefreshFailed;
}

这个接口也有一个RefreshSpanInSecs属性，如果被管理的缓存的RefreshSpanInSecs属性设置的是0，那么管理器将用自身的这个属性对其进行调度。IRefreshableCacheManager接口的RefreshSpanInSecs属性是为了简化那种被管理的所有缓存都采用统一刷新时间间隔的情况而存在的。

RefreshableCacheManager在实现时仍然是借助前面介绍的循环引擎AgileCycleEngine来进行定时控制的。

IRefreshableCacheManager提供了AddCache和RemoveCache方法用于在运行中动态的添加或移除缓存。

当某个缓存在刷新时，抛出异常，则IRefreshableCacheManager会触发CacheRefreshFailed事件，事件参数包含了出现异常的缓存和异常对象。

关于RefreshableCacheManager的实现，要注意以下几点：

（1）管理器的实现是线程安全的，可以使用于多线程的环境中。我们对其内部的缓存列表进行了加锁控制。

（2）管理器在初始化（Initialize）时，启动了循环引擎（其DetectSpanInSecs必须设置为1秒），而且，将所有被管理的缓存的LastRefreshTime都设置为当前时间。

（3）在实现EngineAction方法时，必须在foreach块中使用try来捕捉引擎刷新时抛出的异常，而不是在try块中进行foreach。这个顺序是重要的，如果在try块中进行foreach，那么当一个缓存在刷新时抛出异常而导致foreach中断后，后续缓存的刷新方法都将不会被检测和调用。

（4）使用锁不仅仅是为了同步对内部缓存列表集合的修改，手动调用刷新方法RefreshNow也需要被同步，否则就可能出现两个线程同时进行检测和刷新缓存的情况（一个是循环引擎的线程，另一个是手动调用RefreshNow方法的线程）。

4. 使用时的注意事项

（1）由于管理器内部实现采用了循环引擎，所以定时刷新的时间间隔不可能很精确，而且，针对每个缓存的刷新方法的顺序调用也是导致这种不精确的另一个原因。

（2）也由于管理器内部实现采用了循环引擎，循环引擎能设置的最小检测时间间隔为1秒，所以缓存的刷新时间间隔也不可能小于1秒。

（3）如果某个缓存在刷新时抛出异常，那么其LastRefreshTime属性还是记录的上一次成功刷新的时间。

5.扩展

定时刷新缓存管理器通过事件暴露缓存刷新失败的通知，当缓存刷新发生异常时，我们可能需要将异常记录到日志中。如果是这样，那就可以直接使用ESBasic提供的RefreshableCacheExceptionLogBridge来完成。

RefreshableCacheExceptionLogBridge借助ESBasic.Logger.IAgileLogger组件来将异常的详细信息记录到目标日志中。日志可以是文本文件，也可以是数据库等其他存储。ESBasic提供了IAgileLogger接口的实现FileAgileLogger，用于将日志写入文本文件中。

注：ESBasic源码可到http://esbasic.codeplex.com/下载。
ESBasic讨论QQ群：37677395
ESBasic开源前言

评论: 4　查看评论　发表评论

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

ESBasic 可复用的.NET类库（15）－－对象池 IObjectPool

zhuweisky — Wed, 11 Nov 2009 01:43:00 GMT

阅读: 1564 评论: 1 作者: zhuweisky 发表于 2009-11-11 09:43 原文链接

1.缘起：

对象池应该是一个“历史悠久”的概念了，像我们经常说的线程池、还有ADO.NET中的数据库连接池等，都属于对象池的应用。

我们的应用有时也会碰到需要使用对象池的情况，我举个例子说明一下。假设，我们需要记录某个类MyClass的每个方法每次被调用时方法执行所消耗的时间，而且，这个类是使用在多线程的环境中的，每个方法都可以同时在多个线程中执行，不需要被同步，这样可以使并发达到最大。

好，我们可以使用Stopwatch这个类来准确地记录每个方法的时间，关键是怎么使用它？为MyClass定义一个Stopwatch类型的成员变量，然后在每个方法的开始调用这个成员的Start以启动计时，在方法返回之前记录耗费的时间，然后Reset这个Stopwatch成员。

这种方案只有在一种情况下可以良好工作，那就是要求对MyClass的所有方法的调用都是同步的，而且多个线程调用同一个方法时也必须被同步，否则，Stopwatch的计时就会错乱了。

那么如何解决了？实际上很简单，我们不需要为MyClass定义一个Stopwatch类型的成员变量，而是在每个方法的入口处，new一个Stopwatch类型的局部变量，这个局部变量只服务于当前方法的一次调用。也就是说，对MyClass的任何一个方法的任何一次调用，都会产生一个Stopwatch类型的对象专门用于这次调用的计时工作，当这次调用返回后，该Stopwatch对象就可以被销毁了。这样就可以达到我们最初假设的需求。

从解决方案我们看到，每次调用都会新建一个Stopwatch对象，当调用返回时，这个对象就没有存在的价值而可以被销毁了。这样的结果就是会反复地创建并销毁Stopwatch类型的对象。

这正是使用对象池的一个绝佳场合，我们把一些可用的Stopwatch对象放进对象池中，每次方法被调用时，就向对象池租借一个Stopwatch对象来进行计时，调用返回时，再将这个对象归还给对象池即可。这样就避免了Stopwatch对象的重复创建和销毁。

我设计的ESBasic.ObjectManagement.Pool.IObjectPool就是一个通用的对象池，它是泛型的，所以可以池化存储不同类型的对象。

2.适用场合：

根据我们上面的描述，我们可以总结出当有类似以下的需求时，可以使用对象池技术。

（1）某个类型的对象经常被重复的创建、销毁。

（2）每个该类型的对象被使用的时间都很短。

（3）使用一个共享的对象无法达到系统的要求（比如会限制最大并发量）。

（4）相对于新建或销毁一个对象来说，清除对象的状态要容易得多。

3．设计思想与实现

IObjectPool接口的定义如下：

    public interface IObjectPool<TObject> where TObject : class
    {
        ///

/// MinObjectCount 对象池中最少同时存在的对象数。
///

int MinObjectCount { get;set; }

///

/// MaxObjectCount 对象池中最多同时存在的对象数。
///

int MaxObjectCount { get;set; }

///

        /// DetectSpanInMSecs 当池中没有空闲的对象且数量已达到MaxObjectCount时，如果这时发生Rent调用，则检测空闲对象的时间间隔。
        /// 默认值为10ms。
        ///

int DetectSpanInMSecs { get;set; }

///

/// PooledObjectCreator 用于创建池中对象的创建器。默认为DefaultPooledObjectCreator
///

        IPooledObjectCreator<TObject> PooledObjectCreator { set; }

        void Initialize();

        TObject Rent();
        void GiveBack(TObject obj);
    }

这个接口有一个泛型参数：TObject，表示我们要池化的对象的类型。泛型约束表明能够放入对象池中的对象必须是引用类型。

MinObjectCount属性指示对象池在初始化的时候就必须确保池中存在的对象的数量。

MaxObjectCount属性表示对象池最多能够容纳的对象数量。

如果一个对象被租借出去，则对象池会将其状态标记为“繁忙”的；如果一个对象没有被租借出去或被归还，则其状况就是“空闲”的。

对于ObjectPool的实现，要注意以下几点：

（1）对象池是多线程安全的，可以在多线程的环境下使用。我们对内部的集合进行了加锁控制。

（2）对象池并不直接负责对象的创建工作，它把这项职责委托给了池化对象创建者IPooledObjectCreator。

（3）池化对象创建者IPooledObjectCreator不仅负责对象的创建工作，而且也负责清除对象的状态（Reset方法）。在GiveBack方法的内部就有调用Reset方法来清除对象的遗留状态的。IPooledObjectCreator接口的定义如下所示：

///

/// IPooledObjectCreator 池化对象创建者。用于创建被池缓存的对象。并能清除对象的状态。

///

    public interface IPooledObjectCreator<TObject> where TObject : class
    {
        TObject Create();
        void Reset(TObject obj);
    }

4. 使用时的注意事项

（1）当外部调用Rent方法向对象池租借一个对象时，如果对象池中没有“空闲”的对象，并且池中的对象的数量已经达到了MaxObjectCount，那么这时该如何处理了？ObjectPool采用的策略是选择等待，等待直到有对象变成“空闲”，否则就一直阻塞当前线程。你必须注意到ObjectPool采用的这个策略可能会与你的期望不一致。

（2）当对象池中的空闲对象很多时，即使已经远远地大于了MinObjectCount的值，对象池也不会释放其中的某些对象，而是一直保持着。MinObjectCount只是决定了池在初始化的时候应该创建的对象的数量以备用。

（3）基于上面的两点原因，所以我们在具体应用时需要谨慎地为MaxObjectCount设定一个合理的值。如果这个值太小，可能会使得阻塞线程的情况经常发生。当然，这个值也不是设得越大越好，因为如果平时空闲的对象很多，就表示要占用更多的资源而却没有发挥出相应的价值。

（4）一个从池中借出的对象在被归还回给池的时候，必须把上次使用时遗留的状态清除掉，否则后面的租借者可能会误用其遗留的状态。

（5）如果清除一个对象的状态很不容易，相反创建和销毁一个对象却非常容易，那么这时可以考虑不使用对象池，而是每次new一个对象来使用，使用完了就丢弃掉。

5.扩展

如果我们要池化的对象是没有状态的，而且其类型也有不带参数的默认构造函数，那么我们可以直接使用ESBasic提供的默认池化对象创建者DefaultPooledObjectCreator。DefaultPooledObjectCreator使用反射创建对象，并且Reset方法也不对对象做任何供动作――因为对象本身就是没有状态的，所以也就不存在清除其状态的需要了。

注：ESBasic源码可到http://esbasic.codeplex.com/下载。
ESBasic讨论QQ群：37677395
ESBasic开源前言

评论: 1　查看评论　发表评论

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

ESBasic 可复用的.NET类库（14）－－优先级管理器 IPriorityManager

zhuweisky — Wed, 04 Nov 2009 08:03:00 GMT

阅读: 1431 评论: 2 作者: zhuweisky 发表于 2009-11-04 16:03 原文链接

1.缘起：

假设我们的订单处理系统所要处理的订单是有优先级的，也就是说，不同的订单类型所要求被处理的紧迫程度不同，对那些优先级高的注单要先处理，对于优先级低的注单可稍后处理。对于处于同一优先级的订单了，就按照其到达的先后顺序进行处理。

这是一个典型的管理具有优先级的对象的需求，注单就是具有优先级（With Priority）的对象。我设计了ESBasic.ObjectManagement.Managers.IPriorityManager优先级管理器（确切地说，应该称之为“具有优先级对象的管理器”）来对类似的对象进行管理。

优先级管理器的形象示意图如下：

2.适用场合：

如果你的系统需要对被管理的对象进行优先级分级，并满足以下条件，则可使用IPriorityManager：

（1）对象需要按优先级别（PriorityLevel）进行分类。

（2）优先级别的划分是固定的，不会随系统的运行而发生变化。

（3）对处于同一优先级别的对象，采用先来后到的顺序进行“第二优先级”的高低确定。

（4）优先级别可以使用>=0的连续整数来表示。

3．设计思想与实现

在前面的叙述中，具有优先级对象的管理器的功能职责是相当清晰明了的，在进入其实现之前，首先我们要解决的一个问题是，如何对处于同一优先级别的对象进行管理。根据前面的需求描述，如果两个对象处于相同的优先级别，则先到达的对象的优先程度（即所谓的“第二优先级”）更高。

我使用ESBasic.ObjectManagement.Managers.ISamePriorityObjectManager（同一优先级别对象管理器）来管理属于同一优先级别的所有对象，其接口定义如下：

    public interface ISamePriorityObjectManager<T>
    {
        ///

/// AddWaiter 添加一个等待者。如果等待者在管理器中已经存在，则直接返回。
///

        void AddWaiter(T waiter);

        ///

/// Count 当前管理器中等待者的数量。
///

int Count { get; }

///

        /// GetNextWaiter 返回等待时间最长的waiter。
        /// 注意，返回时并不会从等待列表中删除waiter。如果要删除某个等待者，请调用RemoveWaiter。
        ///

        T GetNextWaiter();

        ///

/// GetWaitersByPriority 按照等待者加入的先后顺序返回等待者数组，数组中index越小的等待者其等待时间越长，其优先级也越高。
///

        T[] GetWaitersByPriority();

        ///

/// RemoveWaiter 从管理器中移除指定的等待者。
///

        void RemoveWaiter(T waiter);

        ///

/// Clear 清空管理器中的所有等待者。
///

void Clear();

///

/// Contains 管理器中是否存在指定的等待者。
///

        bool Contains(T waiter);
    }

在ISamePriorityObjectManager所表述的语义环境中，被管理的对象称为“等待者”waiter――这表示一个对象等待被处理。

关于SamePriorityObjectManager的实现，有以下几点需要说明：

（1）其内部是使用LinkedList而不是Queue来存储等待者的，其主要原因在于SamePriorityObjectManager需要支持移除管理器中任一等待者的RemoveWaiter方法。由于Queue本身不支持任意位置的删除功能，所以我使用了LinkedList。新加入的等待者将被放在LinkedList的最后位置。

（2）当管理器中没有任何等待者时，GetNextWaiter方法将返回default(T)，如果T是值类型，则此时GetNextWaiter返回的可能并不是一个你所期望的对象。所以，如果T是值类型，在调用GetNextWaiter之前先访问一下其Count属性确保管理器中还有等待者存在。

（3）SamePriorityObjectManager使用了前面介绍的SmartRWLocker来对内部的waiterList进行读写锁控制。

在讨论完SamePriorityObjectManager的实现以后，我们将注意力转移到本节的主角IPriorityManager上来，IPriorityManager的接口定义如下：

///

/// IPriorityManager 具有优先级的对象的管理器。
///

    /// 被管理的对象的类型，必须从IPriorityObject继承。
    public interface IPriorityManager<T> : ISamePriorityObjectManager<T> where T : class, IPriorityObject
    {
        int PriorityLevelCount { get; set; }
    }

IPriorityManager接口直接从ISamePriorityObjectManager继承，并没有多加任何方法，唯一增加的就是一个PriorityLevelCount属性和要求被管理的对象的类型必须是从IPriorityObject接口继承的一个泛型约束。

PriorityLevelCount用于设定你的系统需要有几种优先级别。比如，我的订单基于紧急的优先级可分为紧急、普通、不紧急三种，那么就可将PriorityLevelCount属性设置为3。

一个类型从IPriorityObject接口继承，就表明它的实例是具有优先级属性的对象。

///

/// IPriorityObject 具有优先级的对象的接口。
///

    public interface IPriorityObject
    {
        int PriorityLevel { get; }
    }

为什么ISamePriorityObjectManager没有要求被管理的对象继承自IPriorityObject接口了？这是因为在ISamePriorityObjectManager的职责中，其仅仅是根据对象的先后顺序来确定“第二优先级”的，这并不是真正意义上的优先级别，所以没有必要为其单独抽象出一个IPriorityObject接口来。同时，ISamePriorityObjectManager不要求被管理的对象继承自IPriorityObject接口也是为了扩大其被单独复用的范围。

IPriorityManager接口直接从ISamePriorityObjectManager接口继承，说明IPriorityManager实际上要做工作与ISamePriorityObjectManager是相同的，只不过IPriorityManager管理的对象需要首先按优先级别进行分类，然后再使用ISamePriorityObjectManager管理处于同一优先级别的对象。

接下来我们看PriorityManager的具体实现。

在PriorityManager中，有这样的一个约定：优先级别是用int表示的，其值是从0开始连续的一串整数，整数值越小，表明优先级越高。当Initialize方法被执行后，优先等级的范围就被固定下来。比如PriorityLevelCount值设为4，则PriorityManager所支持的优先等级即为：0，1，2，3。

基于这样的约定，PriorityManager内部使用了一个ISamePriorityObjectManager数组，数组的索引值就对应着优先级别值。比如，数组中index为1的ISamePriorityObjectManager管理器中的所有对象的优先级别值都是1。

有了这两点认识，再看PriorityManager的源码就相当容易了，下面是其中的关键点：

（1）在类似AddWaiter、RemoveWaiter这样的方法实现中，都是先通过其参数对象的PriorityLevel属性定位到对应的ISamePriorityObjectManager管理器，然后再做进一步的处理的。

（2）如果目标对象的PriorityLevel属性值超过了约定的范围，PriorityManager会根据当前的情况做灵活的处理。比如，如果是调用AddWaiter加入一个这样的对象，则会抛出一个“不支持该优先级别”的异常；而如果是在类似RemoveWaiter这样的方法中，则会忽略这个对象。

（3）如果PriorityManager管理器中没有任何对象时，PriorityManager的GetNextWaiter方法直接返回null，而不是default(T)，这是因为在PriorityManager定义的泛型约束中，要求T必须是一个引用类型。这就没有了前面提到的SamePriorityObjectManager的GetNextWaiter方法的返回值可能导致的问题。

（4）GetWaitersByPriority方法返回的对象数组具有这样的特征：优先级别越高的对象，其在数组中的位置索引就越小；同一优先级别的对象，加入时间越早的，其在数组中的位置索引越小。

4. 使用时的注意事项

（1）如果你的系统仅仅需要按照对象的到达顺序来决定先后处理的顺序，那么直接使用ISamePriorityObjectManager就可以满足需求了，没有必要使用IPriorityManager这个更复杂的类。使用ISamePriorityObjectManager还有一个好处就是，被管理的对象不需要实现IPriorityObject接口，这样使用起来会更加方便。

（2）如果在你的系统中不是使用0,1,2,3…这样的数值来表示优先级别的，那么你可以建立一个转换映射来完成优先级别值到数字的转换。并遵从PriorityManager所要求的约定。

（3） PriorityManager的Initialize方法一旦被调用后，其PriorityLevelCount属性便不应该被修改。或者说，即使该属性在之后被修改，也不会产生任何效果。

5.扩展

优先级管理器PriorityManager暂时没有任何扩展。

注：ESBasic源码可到http://esbasic.codeplex.com/下载。
ESBasic讨论QQ群：37677395
ESBasic开源前言

评论: 2　查看评论　发表评论

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

ESBasic 可复用的.NET类库（13）－－分组对象管理器 IGroupingObjectManager

zhuweisky — Tue, 27 Oct 2009 07:09:00 GMT

阅读: 1397 评论: 2 作者: zhuweisky 发表于 2009-10-27 15:09 原文链接

1.缘起：

假设我们的订单系统需要管理所有未处理的订单，而客人经常需要查询属于自己的未处理的订单列表。另外，可能客服人员也需要根据订单ID迅速地找到对应的未处理订单。基于第一个需求，我们就可以将未处理的订单依据客人的帐号进行分组管理。

我设计了ESBasic.ObjectManagement.Managers.IGroupingObjectManager分组对象管理器来完成对对象进行分组管理的功能。

分组对象管理器的形象示意图如下：

2.适用场合：

当你的需求覆盖以下条件时，就非常合适使用分组对象管理器：

（1）被管理的每个对象都有唯一的ID。

（2） 被管理的对象可以依据某个标志进行分组。

（3） 经常需要根据分组标志来查询符合该标志的对象列表。

（4）经常需要向管理器中增加/移除被分组的对象。

（5）经常需要根据对象ID快速查找对应的对象。

3．设计思想与实现

IGroupingObjectManager的接口定义如下：

     public interface IGroupingObjectManager<TGroupKey, TObjectKey, TObject> where TObject : IGroupingObject<TGroupKey ,TObjectKey>
    {
        ///

/// Add 如果已经存在同ID的对象，则用新对象替换旧对象。
///

        void Add(TObject obj);

        void Remove(TObjectKey objectID);

        ///

/// Clear 清除所有对象与分组。
///

        void Clear();

        TObject Get(TObjectKey objectID);

        int TotalObjectCount { get;}

        ///

/// GetCountOfGroup 获取某个分组中的对象的个数。
///

        int GetCountOfGroup(TGroupKey groupID);

        ///

/// GetAllObjectsCopy 获取管理器中的所有对象列表。
///

        IList<TObject> GetAllObjectsCopy();

        ///

/// GetGroupsCopy 获取所有的分组标志列表。
///

        IList<TGroupKey> GetGroupsCopy();

        ///

/// GetObjectsCopy 获取某个分组中的所有对象的列表。
///

        IList<TObject> GetObjectsCopy(TGroupKey groupID);
    }

这个接口包含有三个泛型参数：TGroupKey、 TObjectKey和 TObject。

TObject是被管理的对象的类型。

TObjectKey是被管理的对象的ID的类型。

TGroupKey是对被管理的对象进行分组的标志的类型。

另外，该接口的泛型参数还有一个约束，即TObject必须从IGroupingObject接口继承，以表明自己是一个可以被分组的对象。

IGroupingObject接口很简单，其定义如下：

    public interface IGroupingObject<TGroupKey,TObjectKey>
    {
        TObjectKey ID { get; }
        TGroupKey GroupID { get; }
    }

观察这个接口告诉我们，只要一个对象有唯一的ID，并且有分组的标志，那么这个对象就可以被对象分组管理器进行管理了。

关于GroupingObjectManager的实现要注意以下几点：

（1）GroupingObjectManager使用了两个字典集合：objectDictionary 、groupDictionary。objectDictionary用于存储所有被管理的对象。groupDictionary用于管理所有的分组，而且groupDictionary的Value又是另外一个字典，用于存储属于这一分组的所有对象。

（2）GroupingObjectManager的实现是线程安全的，所以可以在多线程的环境中使用。我们对其内部的两个字典集合都进行了加锁控制。

（3）Add方法采用的也是覆盖原则――如果同Key的对象已经存在，则用新对象覆盖旧的对象。

4. 使用时的注意事项

当调用Remove方法删除的是某个分组中的最后一个对象时，在该对象被删除后，对应的分组将也会被删除。所以，管理器中不会存在“空”的历史分组。也就是说，GetGroupsCopy方法返回的分组标志列表中的每个分组标志在管理器中对应的分组都包含至少一个被分组对象。

5.扩展

分组对象管理器IGroupingObjectManager暂时没有任何扩展。

注：ESBasic源码可到http://esbasic.codeplex.com/下载。
ESBasic讨论QQ群：37677395
ESBasic开源前言

评论: 2　查看评论　发表评论

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

ESBasic 可复用的.NET类库（12）－－对象管理器 IObjectManager

zhuweisky — Wed, 21 Oct 2009 01:43:00 GMT

阅读: 1982 评论: 5 作者: zhuweisky 发表于 2009-10-21 09:43 原文链接

1.缘起：

我们经常需要对一些动态对象进行管理，最常见的例子就是在线用户管理。当一个用户成功登陆到服务器后，我们就需要将其管理起来；当他退出后，就不再需要再管理他了。这就是所谓动态对象的含义，这些对象并不是一直需要被管理，只有当其被激活后，才需要被管理。它们总是在“激活”状态和“非激活”状态之间不断地切换。

我设计了对象管理器ESBasic.ObjectManagement.Managers.IObjectManager来管理类似的动态对象。这个类是ESBasic提供的众多对象管理容器中的非常简单的一个，无论是功能还是实现。

对象管理器的形象示意图如下：

2.适用场合：

如果你的系统有类似以下的需求，就可以使用IObjectManager：

（1）将要被管理的每个动态对象都有唯一的ID。

（2）对象经常要被添加到管理器中和经常要从管理器中移除。

（3）管理器在多线程的环境下被使用。

3．设计思想与实现

IObjectManager的接口定义如下：

    public interface IObjectManager<TPKey, TObject>
    {
        event CbGeneric<TObject> ObjectRegistered;
        event CbGeneric<TObject> ObjectUnregistered;

        int Count { get; }

        ///

/// Add 如果已经存在同ID的对象，则用新对象替换旧对象。
///

        void Add(TPKey key, TObject obj);

        void Remove(TPKey id);
        void Clear();
        bool Contains(TPKey id);

        ///

/// Get 如果不存在，则返回default（TObject）。
///

        TObject Get(TPKey id);

        IList<TObject> GetAll();
        IList<TPKey> GetKeyList();
        IList<TPKey> GetKeyListByObj(TObject obj);
    }

这个接口相当简单，就像是一个IDictionary的加强版。是的，你确实可以这样理解，把IObjectManager当作一个更好用的字典。而且ObjectManager的实现也的确是使用IDictionary来的。

但是它与IDictionary的区别――也是它更好用的地方在于：

（1）它是多线程安全的，可以再多线程的环境下被使用。与IDictionary相比，这应该是最大的一个易用点。

（2）Add方法采用的是覆盖原则――如果同Key的对象已经存在，则用新对象覆盖旧的对象。当然，如果你不想直接覆盖，再调用Add方法之前可以先调用Contains方法检测一下。

（3）当调用Remove方法从管理器中移除一个不存在的对象时，并不会抛出异常，而是直接返回。

（4）GetKeyList方法返回的是键值的拷贝，这样在对返回列表做foreach遍历时，即使内部字典中的元素发生了增加/删除也不会影响遍历操作。

（5）当内部集合的元素发生增加/删除时，以事件（ObjectRegistered事件和ObjectUnregistered事件）的方式通知外部。

4. 使用时的注意事项

IObjectManager的两个泛型参数都是没有泛型约束的，也就是说TObject可以是值类型。当TObject是值类型时，如果使用一个不存在的ID去调用Get方法，则不会返回null，因为值类型不可能为null，这时将返回default(TObject)。而这样的结果也许并不是你所期望的。

所以，如果你的TObject为值类型，又不想出现上面的情况，那么在调用Get方法之前有必要先调用Contains方法确认一下对象是否真的存在――这就像在使用IDictionary一样。

5.扩展

对象管理器IObjectManager暂时没有任何扩展。

注：ESBasic源码可到http://esbasic.codeplex.com/下载。
ESBasic讨论QQ群：37677395
ESBasic开源前言

评论: 5　查看评论　发表评论

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

ESBasic 可复用的.NET类库（11）－－双向映射 IBidirectionalMapping

zhuweisky — Thu, 15 Oct 2009 02:49:00 GMT

阅读: 1655 评论: 4 作者: zhuweisky 发表于 2009-10-15 10:49 原文链接

1.缘起：

假设我们的用户管理系统要求用户的ID和Name都必须是唯一的，并且用户的ID和Name一经确定就不能被修改。而且管理系统经常需要根据ID来查找Name，也经常需要根据Name来查找ID。根据这样的需求，我们可以考虑使用一个Dictionary来将ID和Name缓存起来，通常ID作为Key，Name作为Value。这样便可实现通过ID查询Name的快速查找，但是，通过Name查找ID就不是那么快了，因为涉及到对Dictionary的Values做遍历的操作。那么，有可能使得通过Name查找ID的速度与通过ID查找Name的速度一样快吗？

于是，我设计了ESBasic.ObjectManagement.Cache.IBidirectionalMapping（双向映射）来解决这个问题。

双向映射的形象示意图如下：

2.适用场合：

如果满足以下的条件，则可以使用双向映射：

（1）Key是唯一的，Value也是唯一的。

（2）需要对Key和Value做缓存。

（3）经常需要根据Key来查找Value。

（4）经常需要根据Value来查找Key。

3．设计思想与实现

IBidirectionalMapping接口定义如下：

///

    /// IBidirectionalMapping 双向映射。即Key和Value都是唯一的，在这种情况下使用IBidirectionalMapping可提升依据Value查找Key的速度。
    /// 该接口的实现必须是线程安全的。2008.08.20
    ///

    public interface IBidirectionalMapping<T1, T2>
    {
        int Count { get; }

        ///

/// Add 添加映射对。如果已经有相同的key/value存在，则会覆盖。
///

        void Add(T1 t1, T2 t2);

        void RemoveByT1(T1 t1);
        void RemoveByT2(T2 t2);

        T1 GetT1(T2 t2);
        T2 GetT2(T1 t1);

        bool ContainsT1(T1 t1);
        bool ContainsT2(T2 t2);

        ///

/// GetAllT1ListCopy 返回T1类型元素列表的拷贝。
///

        IList<T1> GetAllT1ListCopy();

        ///

/// GetAllT2ListCopy 返回T2类型元素列表的拷贝。
///

        IList<T2> GetAllT2ListCopy();
    }

该接口使用了两个泛型参数，根据上面的描述，一个泛型参数表示Key的类型，另一个泛型参数表示Vlaue的类型。由于，在双向映射中，Key和Value是对称的，所以我没有使用TKey和TValue来命名它们，而是使用T1和T2。

在实现BidirectionalMapping时，我们使用两个Dictionary来完成双向映射的功能。一个Dictionary以T1为Key，T2为Value；另一个刚好反过来。

在实现的具体过程中，要注意以下几点：

（1）为了允许在多线程的环境中使用双向映射，所以BidirectionalMapping必须在对内部Dictionary操作的时候进行加锁控制。

（2）在实现Add方法添加一个“映射对”的时候，必须判断当前是否已经存在了相同的值，如果存在，则先删除旧的映射对，再添加新的映射对。

（3）要注意一个细节，GetAllT1ListCopy和GetAllT2ListCopy的实现都使用了lock，这是因为在拷贝的时候会对其Keys或Values进行foreach遍历，而在对Dictionary中的元素进行foreach遍历的时候，如果同时向其中添加或删除元素，则foreach操作是会抛出异常的。

4. 使用时的注意事项

BidirectionalMapping提升了通过Name查找ID的速度，这是通过使用了更大的内存来做到的，是典型的“空间换时间”的例子。所以，对于巨大规模的映射对的缓存，要注意内存的使用问题。

另外，映射对中的两个元素的类型不一定非是ID或Name这样的简单对象，实际上，非常复杂的对象也可以缓存在双向映射中，只要其GetHashCode方法实现的恰当就不会有任何问题。

5.扩展

       双向映射BidirectionalMapping暂时没有任何扩展。

注：ESBasic源码可到http://esbasic.codeplex.com/下载。
    ESBasic讨论QQ群：37677395
    ESBasic开源前言

评论: 4　查看评论　发表评论

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

博客园-zhuweisky

ESBasic 可复用的.NET类库（20） －－ TopN排行榜容器 TopNOrderedContainer

ESBasic 可复用的.NET类库（19） －－ 热缓存 IHotCache

ESBasic 可复用的.NET类库（18） －－ 智能字典缓存 ISmartDictionaryCache

ESBasic 可复用的.NET类库（17） －－ 对象获取器IObjectRetriever

ESBasic 可复用的.NET类库（16） －－ 定时刷新缓存管理器 IRefreshableCacheManager

ESBasic 可复用的.NET类库（15） －－ 对象池 IObjectPool

ESBasic 可复用的.NET类库（14） －－ 优先级管理器 IPriorityManager

ESBasic 可复用的.NET类库（13） －－ 分组对象管理器 IGroupingObjectManager

ESBasic 可复用的.NET类库（12） －－ 对象管理器 IObjectManager

ESBasic 可复用的.NET类库（11） －－ 双向映射 IBidirectionalMapping

ESBasic 可复用的.NET类库（20）－－ TopN排行榜容器 TopNOrderedContainer

ESBasic 可复用的.NET类库（19）－－热缓存 IHotCache

ESBasic 可复用的.NET类库（18）－－智能字典缓存 ISmartDictionaryCache

ESBasic 可复用的.NET类库（17）－－对象获取器IObjectRetriever

ESBasic 可复用的.NET类库（16）－－定时刷新缓存管理器 IRefreshableCacheManager

ESBasic 可复用的.NET类库（15）－－对象池 IObjectPool

ESBasic 可复用的.NET类库（14）－－优先级管理器 IPriorityManager

ESBasic 可复用的.NET类库（13）－－分组对象管理器 IGroupingObjectManager

ESBasic 可复用的.NET类库（12）－－对象管理器 IObjectManager

ESBasic 可复用的.NET类库（11）－－双向映射 IBidirectionalMapping