zhuweisky

       在开发ERP系统的数据报表时，几乎都是需要看到【小计】、【总计】这样的汇总数据的，在数据报表的显示列表中，最下面的一行通常就是【小计】或者【总计】的汇总行。如果手动为每个报表都增加汇总行，那也是一份不小的工作量。　　所以，如果能自动为每个数据报表自动添加【小计】、【总计】汇总行，那将可以节省不少的开发时间。本文将给出实现这种方案的思路原理以及源码。　　本文中，报表数据的显示使...

1.缘起：    我们还是以多叉树IMultiTree章节介绍的那个例子来继续讲解。假设，在系统运行的过程中，集团又成立了分公司D及其下属的一些单位，这些资料已经被存入了数据库中，但是这些信息在我们当前正在运行的MultiTree实例中并不存在，如果此时向MultiTree实例请求与D分公司相关的信息，那么将一无所获。除非，你手动地将D分公司及其下属单位的节点值添加到MultiTre

1.缘起：    假设我们的订单报表系统，需要能够实时地统计当天的已成交订单的报表。最直观的解决方案就是，当每次接收到查询报表的请求时，就从存储设备读取当天所有已成交的订单，然后再进行分析计算给出结果。这是可行的，而且得到的结果也是非常实时的。但是，这种方式无疑也是非常低

1.缘起：    在增量自动获取器章节的缘起部分，我们曾提到增量缓存，本节我们将深入探讨它以及用于管理增量缓存的管理器。我们还是以增量自动获取器章节提到的例子作为基础，并做更进一步的讨论。      OK，现在让我们开始这有趣的旅程。首先，基于前面例子给出的上下文，我

<br />1.缘起：<br />    从IMultiTree到IAgileMultiTree，一切进展得都不错。但是，还有改进的地方。多叉树的一个优点在于，根据指定的节点能够非常迅速地找到其所有的子节点。但是缺点在于，根据节点值的ID定位到目标节点不够快，因为需要对所有的节点进行遍历操作。当节点非常多、层次非常深时，这种定位操作可能会严重的影响效率。<br />    我设计了层级结构缓存ESBasic.ObjectManagement.Cache.IHiberarchyCache来加速这种根据节点值I

1.缘起：    假设我们要描述一个集团公司的组织结构，这个集团公司的体系分为如下几层：集团、公司、子公司、部门、小组。即一个集团由多个公司构成，每个公司又有几个子公司构成，每个子公司拥有多个部门，每个部门又内分为几个小组。    很明显，这种体系结构就是一个多叉树。我设计了ESBasic.ObjectManagement.Trees.Multiple.IMultiTree来抽象

1.缘起：    当数据源中的数据量多到一定程度时，我们在查询时就经常使用分页策略。如果数据源是一个完整的整体，这没有什么大不了的，我们经常就在做类似的事情。但是，如果数据源不是一个完整的整体，而是由很多有序的片段构成的，并且不同的片段可能位于不同的位置（比如，位于不同的服务器节点上的内存中），甚至，每个片段内的数据还会随着时间的变化而变化的。    在这种假设的情况下，来从这个

自从03年正式使用.NET开发以来，已经走过了6个年头，这期间我积累了几套类库和框架，ESBasic便是其中最基础的一个类库。ESBasic是Enterprise Service Basic的缩写，虽然也简写为ESB，但是它和Enterprise Service Bus（企业服务总线）没有任何关系。ESBasic是我能够快速和高效开发应用程序的利器之一，开这个专门的blog是想将它介

          （如果您能对照着源码来阅读本文，效果会更好。） 1.缘起：       假设我们的员工打卡系统，需要设定公司规定的上班时间、下班时间、以及还要对员工是否迟到早退等这些情况进行判断。       我们以什么方式来记录类似上下班时间这样只有时分秒没有年月日的时间了？你说可以使用DateTime，但是合适吗？总是觉得用DateTime来表示上下班的时间很别扭

  1.缘起：     同我们从DateTime中将时刻部分作为ShortTime抽离出来一样，我们将DateTime中的日期部分也抽离出来，以ESBasic.Date类来表示。    比如，我们的报表系统是以“天”为单位来进行统计的，为了提高效率，我们会在每天凌晨将前一天的报表数据统计完毕，并存储到数据库中，一天的报表数据就对应数据库数据库中的一条记录，该记录以一个表示日期的整

  1.缘起：    假设我们要开发一个多人跳棋游戏。在跳棋游戏中，当一个人走一步棋之后，控制权就轮到下一家，如此轮询，一圈之后控制权又回到自己，然后再继续轮圈下去。我们可以使用数组或列表等数据结构来解决这种转圈圈的问题，但是始终都不够直观。    我设计了Circle来对“圈”这种数据结构进行抽象，我们在类似跳棋这样的游戏中可以非常方便地直接使用它。Circle的形象示意图

 1.缘起： 有些系统需要每隔一段时间就执行一下某个动作，比如，一个监控系统每隔10秒钟就要检测一下被监控对象的状态是否正常，那这时我们就可以用到循环引擎了。    有人说可以使用.NET框架自带定时器如System.Threading.Timer，嗯，没错。但是若这个类使用不当可能会引发后台池线程耗尽的后果。因为Timer的定时事件触发实在后台线程池中的某个线程中处理的。也就是

1.缘起：     假设我们的系统在运行的过程中，源源不断的有新的任务需要处理（比如订单处理），而且这些任务的处理是相互独立的，没有前后顺序依赖性（顺序依赖性是指，必须在任务A处理结束后才可开始B任务），那么我们就可以使用多个线程来同时处理多个任务。每个处理任务的线程称为“工作者（线程）”。      我设计了ESBasic.Threading.Engines.IWorkerEngi

 1.缘起：     假设我的订单处理系统有这样的需求：将一天24小时分为4个时段，凌晨2:15到8:30采用A类型的处理器处理接收到的订单，8:30到14:00采用B类型的处理器，14:00到20:00采用C类型的处理器，20:00到第二天凌晨2:15采用D类型的处理器。    即我们的订单处理器需要在任一天的2:15、8:30、14:00、20:00这四个时刻发生切换，这就是

 1.缘起：     举个例子也许就能够说清楚回调定时器的用途。假设我的订单系统接收各种不同类型的订单，当订单A进来时，系统根据订单的类型和其它特征进行综合判断后，决定A订单要在2秒之后被方法M1处理；接下来收到的B订单经过同样的判断后，决定要在10秒后被方法M2处理，……。这时候就可以用回调定时器来管理这些将要被延迟一定时间再执行的任务。    当然，我们可以使用定时器或前面介

1.缘起：    对于需要进行线程同步的地方，我们经常用的就是.NET内置的lock关键字和ReaderWriterLock类。lock的功能相对简单，因为它不区分读写，也就是说如果都在lock块中，读线程都会阻塞另一个读线程，在很多读远远多于写的应用中，这会极大地折损性能。所以我们也经常需要使用读写分离的锁ReaderWriterLock，使用它，我们可以明确的指定是要获取“读”锁

1.缘起：    假设我们的用户管理系统要求用户的ID和Name都必须是唯一的，并且用户的ID和Name一经确定就不能被修改。而且管理系统经常需要根据ID来查找Name，也经常需要根据Name来查找ID。根据这样的需求，我们可以考虑使用一个Dictionary来将ID和Name缓存起来，通常ID作为Key，Name作为Value。这样便可实现通过ID查询Name的快速查找，但是，通过

1.缘起：    假设我们的C/S系统中服务端与客户端之间采用UDP进行通信，那么服务端如何知道每个客户端当前是否仍然在线了？有可能某个客户端一直没有退出，但是在很长一段时间内都没有与服务端作任何通信，那么服务端就应该认为这个客户端已经离线了吗？为了能让服务端掌握每个客户端是否在线的状态，我们可以这样做，只要客户端一启动起来，就每隔一段时间间隔（如10秒）就向服务端发一个“我还在线”

1.缘起：   假设我们有一个会员管理系统，需要向各方提供查询会员基础资料的功能。会员一经注册，其基础资料就将不再发生变化（如会员帐号、身份证ID、注册时间等等）。   基于这样的需求，我们可以将会员的基础资料“永久地”缓存在内存中，从而提升对任何一个会员基础资料的查询速度。   我设计了ESBasic.ObjectManagement.Cache.ISmartDiction

1.缘起：ESBasic中许多管理对象的容器都用到了这个ESBasic.ObjectManagement.IObjectRetriever接口，所以单独将其提出来介绍一下。当我们向对象容器（Container）请求某个对象时，也许目标对象还未加载到容器中，这可能是因为容器在初始化的时候就没有加载这个对象，也有可能是因为这个对象是容器初始化以后新增到数据库（当然也有可能是其它的持久

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

1.缘起：    为了提升系统的性能或减轻数据库的压力等原因，我们经常在系统中使用缓存来把那些经常使用的数据保留在内存中。如果因为某些原因，缓存中这些经常使用的数据不能及时与数据源进行同步更新，那么采用定时刷新缓存中的数据有可能就是一种合适的选择。    如果你的缓存是定时刷新，那么你就需要自己为其维护一个定时器或循环引擎。如果你的系统中像这样定时刷新的缓存有多个，而且每个缓存定

1.缘起：    对象池应该是一个“历史悠久”的概念了，像我们经常说的线程池、还有ADO.NET中的数据库连接池等，都属于对象池的应用。    我们的应用有时也会碰到需要使用对象池的情况，我举个例子说明一下。假设，我们需要记录某个类MyClass的每个方法每次被调用时方法执行所消耗的时间，而且，这个类是使用在多线程的环境中的，每个方法都可以同时在多个线程中执行，不需要被同步，这样

1.缘起：    假设我们的订单处理系统所要处理的订单是有优先级的，也就是说，不同的订单类型所要求被处理的紧迫程度不同，对那些优先级高的注单要先处理，对于优先级低的注单可稍后处理。对于处于同一优先级的订单了，就按照其到达的先后顺序进行处理。    这是一个典型的管理具有优先级的对象的需求，注单就是具有优先级（With Priority）的对象。我设计了ESBasic.Object

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

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

1.缘起：    假设我们的报表系统需要在每天的00:05:00统计前一天的报表数据，需要在每周一的00:30:00统计上周的报表数据，又需要在每月1日的00:30:00统计上月的报表数据。这些报表统计任务是很常见的系统需求，对于类似这样的在指定时刻执行的定时任务，我使用ESBasic.Threading.Timers.TimingTaskManager（定时任务管理器）来处理它