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命名空间提供了IIntegratedCustomizeHandler接口 -- 可被集成的处理器接口,其定义如下所示:
///<summary>
/// 能够被ComplexCustomizeHandler集成的ICustomizeHandler。
///</summary>
public interface IIntegratedCustomizeHandler :ICustomizeHandler
{
///<summary>
/// 当前的处理器能否处理目标类型的自定义信息。
///</summary>
///<param name="informationType">自定义信息的类型</param>
///<returns>能处理?</returns>
bool CanHandle(int informationType);
}
IIntegratedCustomizeHandler从ICustomizeHandler继承,说明它可以做与ICustomizeHandler完全一样的事情,只不过,它处理的是整个业务逻辑的一个子集。其增加的CanHandle方法用于说明当前处理器能处理哪些自定义信息。ACustomizeHandler、BCustomizeHandler、CCustomizeHandler 只要实现IIntegratedCustomizeHandler接口就可以了。处理器实现新加的CanHandle方法很简单,比如BCustomizeHandler实现CanHandle的代码如下所示:
public bool CanHandle(int informationType)
{
return informationType >= 101 && informationType <= 200;
}
在实现完了各个业务处理器之后,接下来就需要将它们合成起来,并挂接到ESFramework/ESPlus框架上。
三.分而治之的合成阶段
先分后合,分而治之的最后阶段是“合”,只有将ACustomizeHandler、BCustomizeHandler、CCustomizeHandler统合起来,才能形成一个完整的业务处理器以处理接收到的所有自定义信息。
ESPlus.Application.CustomizeInfo命名空间提供了ComplexCustomizeHandler类,它是一个综合处理器,相当于一个包装,可以把ACustomizeHandler、BCustomizeHandler、CCustomizeHandler综合在一起,并且ComplexCustomizeHandler又实现了IIntegratedCustomizeHandler接口,这表明了两点:
- ComplexCustomizeHandler实现了IIntegratedCustomizeHandler接口,而IIntegratedCustomizeHandler又是继承自ICustomizeHandler接口,所以可以将其直接挂接到ESFramework/ESPlus框架。
- ComplexCustomizeHandler实现了IIntegratedCustomizeHandler接口,表明其可以再度被其它的ComplexCustomizeHandler集成。就像在一个巨型的系统中,业务逻辑可以被逐级向下拆分,最后可以通过ComplexCustomizeHandler逐级向上合成。
ComplexCustomizeHandler的实现原理很简单,它只是将接收到的自定义信息分派给正确的处理器去处理,而自己并不参与任何实际的业务过程。其类图如下所示:
针对上面的示例,我们将ACustomizeHandler、BCustomizeHandler、CCustomizeHandler的实例放到ComplexCustomizeHandler的HandlerList中,并且将ComplexCustomizeHandler对象注入到RapidPassiveEngine和RapidServerEngine的Initialize方法中,即可挂接到ESFramework/ESPlus框架。
四.更多说明
虽然,ESFramework/ESPlus为分而治之这种策略提供了很好的支持,但这并不是实现分而治之策略的唯一的模式。您完全可以抛开IIntegratedCustomizeHandler和ComplexCustomizeHandler,按照自己的习惯和方式,来拆分业务逻辑并进行合成,最后也会殊途同归--只要我们遵循了“低耦合、高内聚”这一最根本的设计原则。
Q Q:168757008