基于IoC思想设计的系统架构
作者：成晓旭
http://blog.csdn.net/CXXSoft/
(声明：版权保留，欢迎转载、请保证文章完整性)
1. 引言
Java领域的开发人员，可以采用spring开源框架，快速构建自己的业务应有系统，本人羡慕不已。但是在我采用的传统开发语言、专业应用领域，都没有这样的好框架可以沿用。于是早有自己设计一个IoC框架，适用于本人涉及的实时监控、通信采集领域。
“他山之石、可以攻玉”。其实IoC、DI等的分析、设计理论未必非要用来构架通用的基础开发框架，在具体的应有系统开发中借用，同样能构建灵活的系统体系架构，尤其是对于企业战略性的长期的产品、系统的构建，更是事半功倍。
2. 系统背景简介
在实时监控、数据采集等通信类系统中，通常的设计都是：将数据采集或者与底层逻辑单元（比如：底层的软件子系统、硬件终端、远程设备）通信的逻辑功能独立封装在一个子系统中，实现基础通信收发、通信方式分化、通信流程控制、底层协议规整、基础数据整合等网络通信、数据采集职责。
本设计是针对常见的实时监控、数据采集系统。下面以一个典型的通信采集服务器应有为例：系统的底层是硬件采集设备，硬件设备完成整个系统与外界环境或者设备的交互；上层的软件系统完成与自己硬件设备的交互，并且对采集的数据进行分析、处理、存储、与外部系统接口。
3. 问题
在我工作的软件项目中，类似的应用存在于多个软件系统中，虽然这些系统在子系统设计及职责划分方面也如上图一般进行了明确的分层及模块化，但在核心的“通信采集子系统”的设计及实现上存在诸多通病，导致整个子系统的可理解性、可维护性、可测试性、对需求变动的适应性极差。集中表现在：
1. 整个系统被设计成一个“非常庞大”的“业务调度控制类”，没有进行职责的拆分和封装；
2. 在通信方式实现类（比如：串口通信类、语音卡控制类、TCP/IP通信类）中完成所有业务处理功能；（绝大多数板卡厂商Demo程序是这样演示的，有意无意间误导了很多刚刚接触CTI、IVR系统开发的入门者）
3. 对于多任务并发，多个设备上、下行同时通信的管理非常复杂；
4. 对于需求变化的适应性非常差；
5. 系统代码几乎没有可复用性了。
4. 新问题
针对上述问题，总结、分析以往经验和教训，以“代码复用”为出发点重新设计了通信采集系统体系架构，并较好地解决这些突出问题，并梳理出大量可复用的功能代码。详细说明请参考《一个典型的采集服务器体系结构设计》一文：http://blog.csdn.net/cxxsoft/archive/2006/09/18/1236331.aspx。
但是，后来再次开发通信采集服务器，以应有于不同的业务需求时，发现原来的架构存在如下的典型问题：
1、“采集控制器”几乎不能重用、但与新开发的采集控制模式非常相识。但是，每次新开发的“采集控制器”逻辑都非常相识，但必须修改业务采集类的类名和方法名，修改状态机的转换关系，修改协议调用的类名和方法名。
2、“业务采集类”的变化，会直接影响到“采集控制器”。
3、“通信协议类”的变化，会直接影响到“采集控制器”。
4、通信控制流程、时序的变化，会直接影响到“采集控制器”。并且要正确实现这些变化，必须在与此无关的“采集控制器”中，小心翼翼地扣代码出来改。
5. IoC重构设计
开源的通用采集服务器，是在原有系统架构的基础上，增加业务抽象接口，引用IoC的设计理念，倒置交互类之间的依赖关系，采用DI来实现类之间的依赖关联的动态关联。
1、 抽象“业务调度核心类”的核心逻辑流程，将所有类方法的调用设计成对接口方法的调用。
2、 抽象“采集控制类”的核心逻辑流程，将所有类方法的调用设计成对接口方法的调用。“采集控制器”类被设计成一个通用的“工控机主板”，只要遵循“主板”约定的接口，换插不同的“业务采集类”、“通信协议类”，可以实现完全不同的采集业务需求、按照完全不同的通信协议与底层模块通信。
3、 将“采集控制类”中的状态机管理逻辑剥离出来，将状态机检测和控制代码设计成对接口方法的调用。只要遵循状态机接口，可以灵活实现不要业务需求的状态转换控制，在运行期动态创建状态机实例，并注入到“采集控制类”，完全接触“采集控制器”与“业务状态机类”静态依赖。
4、 去掉“通信适配器”、“协议适配器”，增加“通信接口”、“协议接口”和“业务接口”，按照接口要求重构通信类、协议类、采集业务类，解决原来系统架构中：新增一种通信方式、通信协议时，还必须在相关的适配器中增加新类型识别代码的设计弊端。
6. 技术基础与规约
本设计的核心的设计原理：IOC容器根据反射机制动态创建实现约定接口的业务对象，动态注入到采集调度控制器中。采集调度控制器是一个高层次抽象的Active Class，自动不断地调用状态机接口方法来执行“业务采集类”要求的业务通信指令。
本设计的核心的重要设计约定：采集调度控制器只调用抽象的接口方法，那么具体的上层业务任务，如何动态的翻译成具体的通信协议？又如何知道当前的任务如何开始，何时结束？本设计要求：业务采集类必须管理好自己的业务步骤与通信协议之间的对应关系（确实非常难以在抽象，用动态配置的方法使用起来反而更复杂），采集调度控制器只负责动态建立两者之间的运行期对象关系。业务采集类必须实现采集调度控制器要求的指定接口方法，用以实现采集任务的发起、执行下一条指令、结束、异常重发、异常中止、故障处理等采集流程控制功能。这正好是采集调度控制器高层抽象的价值和通用性的设计基础。
框架使用者只需按照接口约定，编码实现具体业务需求的相关采集、状态机、协议业务类；在配置这些类的运行期参数，采集服务器大功告成。采集服务器在允许时，会自动加载配置参数，动态创建相关的业务逻辑对象，并完成依赖注入，整个系统能按具体的业务要求完成通信、采集任务。
7. 采集服务器设计
通信采集服务器是常常是实时监控、数据采集类系统的核心，实现与底层的软件子系统、硬件终端、远程设备的通信、下行命令的执行、上行数据的接收、协议解析，并且完成业务数据的分析以及显示驱动。它既是系统的通信枢纽，也是业务核心。
