ESFramework 使用技巧 －－ 信息处理，分而治之
ESFramework开发手册系列文章已经详细介绍了如何使用ESPlus提供的ESPlus.Application.CustomizeInfo空间来发送和处理自定义信息，而且，在我们在前面介绍的demo中，也展示了如何定义信息类型、信息协议，以及如何实现ICustomizeHandler来处理接收到的信息。在一般业务简单的系统中，我们完全可以像demo一样，在一个CustomizeHandler类中处理所有的信息，将所有的业务逻辑集中在这一个地方。但是，当业务逐渐变得复杂时，你会发现，CustomizeHandler类会变得越来越大，而且有很多关联不大的业务逻辑也纠缠在了一起。根据“低耦合、高内聚”的设计原则，我们需要对这个变得复杂的CustomizeHandler进行拆分，将一个CustomizeHandler拆分为多个高内聚低耦合的类，对收到的信息进行分类，分而治之。
?
一.分而治之的设计阶段就像刚才提到的，分而治之的所依据的最根本原则是面向对象的基本设计理念 -- 高内聚、低耦合。
在实际的项目中，高内聚、低耦合所针对的分析目标就是我们的业务逻辑， 所以，对CustomizeHandler进行拆分，实际上是对业务逻辑进行拆分。再进一步，那些将被处理的自定义信息，实际上是业务逻辑类型的一个侧面的展示，所以，归根到底，在编码时，最后就是对自定义信息的类型进行拆分。
假设某个项目的主要业务逻辑可以拆分为A、B、C三类，那么，自定义信息也可以分为A、B、C三类，我们的经验是这样的，将不同类别的信息类型的值（整数）划归到不同的整数段。比如，A类型的自定义信息的类型值为0-100，B类型为101-200，C类型为201-300，当我们要在某类业务逻辑中增加一个信息类型时，就要在对应的数值范围内增加一个数值。这样处理之后，当我们接收到一个自定义信息，根据其类型就可以判断出它是属于哪类业务的了。
在做系统设计时，我们的设计师通常会将所有的信息类型整理成一个“协议类型”文档并将其定义放到一个dll中，服务端和客户端开发人员都使用这个dll的定义，并遵循文档中的信息类型的规范描述。比如，针对上面的示例可以设计类似如下的“协议类型”文档：
?
二.分而治之的实现阶段在将自定义信息分类并完成了信息的格式约定后，就可以实现信息处理器了。针对A、B、C三类业务，理所当然地，我们会实现三个信息处理器分别与之对应，假设命名为ACustomizeHandler、BCustomizeHandler、CCustomizeHandler。现在的问题是，实现了这几个处理器之后，如何将它们挂接到ESFramework/ESPlus框架上了？幸运的是，ESFramework/ESPlus为分而治之这种策略提供了完美的支持，我们不需要再手动去映射信息类型与对应的处理器。
ESPlus.Application.CustomizeInfo命名空间在服务端（Server）和客户端（Passive）都提供了IIntegratedCustomizeHandler接口 -- 可被集成的处理器接口，其定义如下所示：
