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

官网:www.oraycn.com

导航

首页

官方网站

立即咨询 

站内搜索

ESFramework 通信框架

详细说明

SDK下载

ESFramework FAQ

版本变更记录

OMCS 语音视频框架

详细说明

SDK下载

OMCS FAQ

版本变更记录

OrayTalk 企业即时通讯系统

详细说明

客户端下载

傲瑞实用组件

SDK下载

NPush 消息推送组件

StriveEngine 轻量级的通信引擎

MFile 语音视频录制组件

MCapture 语音视频采集组件

MPlayer 语音视频播放组件

OAUS 自动升级系统

傲瑞组件 FAQ

授权

授权流程

产品授权说明

产品选购指南

授权SDK使用说明

其它

SDK使用技巧

联系我们

电话:027-87638960

Q Q:168757008

邮件:master@oraycn.com