CnPack Forum - Powered by Discuz! Board

Subject: CnPackTip#7 一种底层通信实现与业务逻辑分离的简要架构设计 [Print This Page]

Author: skyjacker Time: 2007-5-17 11:05 Subject: CnPackTip#7 一种底层通信实现与业务逻辑分离的简要架构设计

CnPackTip#7 一种底层通信实现与业务逻辑分离的简要架构设计

http://www.cnpack.org
CnPack IV  QQ Group: 130970
感谢: Victor.Woo, 唐光杰, Passion ...
整理: SkyJacker
2007.01.27

需求:
要做的系统是整合温湿度、门禁系统为一个通用的系统，并且协议可以任意扩充，界面要求基本不变。
温湿度或门禁系统协议繁多，与厂家提供的模块协议有关。
更进一步说不光是温度或者门禁系统,还有其它各种采集和控制系统。
需要整合不同的协议，并可以方便的接入本系统。

SkyJacker:
初步打算用dll插件方式实现以下功能。
流程描述：
  界面程序(JieMian)，通讯程序(TongXun)。
  1、通讯程序主动上报数据给界面程序，界面程序将数据存入数据库并刷新当前状态界面。
  2、界面负责接收用户执行操作，然后界面程序将用户命令发给通讯程序，通讯处理完毕后，
   发给界面，由界面通知用户。
  3、界面程序、通讯程序都需要操作数据库。通讯程序主要是查询数据库。
   界面程序作为主程序JieMian.exe；
   通讯程序用dll；
   由于通讯程序可能会根据不同的协议而改变，因此要协议不同而制作多个通讯插件，以备用。
   使用时，只需要更换通讯插件即可。

框架讨论:

Victor.Woo:
使用Proxy Pattern。
自己写一个虚拟父类，或者方法，定义公用的接口。
然后温度、湿度的具体业务，继承父类。然后通过proxy来具体地调某个对象的方法。
WinAmp就是这样做的。

比如我写得一个网络程序，可以支持tcp/udp，根据用户喜好。
我就自己实现了一个 TCustomClient，有Connect,Disconnect，Send等方法，
派生出TTcpClient和TUdpClient，根据实际的需要调用。

唐光杰：
写3个基类。
1、通道一个类（RS232、RS485、Eth、TCP、UDP等等）
2、设备一个类（具体的通讯设备）
3、协议一个类。那么以后再扩充协议的时候，从这三个类继承下来。

协议在变化，采用的通道也可能不同。一套组态系统采用的协议一般都有10多个。

Passion:
这种设计类似于CnDebug中的消息发送通道TCnDebugChannel的设计。
TCnDebugChannel是CnDebug中定义的用于进行具体消息发送的基础类，提供发送一片内存区域内容的基本接口。
CnDebug的上层组装好了待发送内容后便调用一个TCnDebugChannel的实例的发送接口进行发送。
而发送的具体实现在一个TCnDebugChannel的子类中实现，目前是TCnMapFileChannel，
它实现了和CnDebugViewer进行共享内存交互的功能。
如果需要不同的发送内容，重新继承一个TCnDebugChannel的子类并自行实现发送功能即可。

Author: 小雨哥 Time: 2007-5-22 01:46

这个命题，感觉是一个标准的插件框架命题。Proxy 的思路非常好。可以更深入考虑 Proxy 思路，就是把业务框架
和数据流分离，只有数据流才涉及到协议，业务流程与协议无关。Proxy 用来调和协议差异，甚至把 Proxy 做得很
薄，仅仅调用与协议注册相关的具体协议解释器，于是，可以一古脑儿地把支持的协议插件统统放进去，实现自动
调用。

Author: skyjacker Time: 2007-5-22 11:33

终于盼来小雨哥了
庆祝一下

Author: skyjacker Time: 2007-5-22 13:02

这个简明的介绍也不错.
http://www.sunistudio.com/nicrosoft/dispArticle.Asp?ID=15

这种思想的确很重要.
我想它会一直伴随着程序人生,因此需要不断消化.

最近正在按这种思想实现一自动化控制流程模块,受益匪浅。
模块流程思想如下：

界面(显示、配置) <—> 自动化控制流程（业务逻辑）<—> 通道(RS232….)
                                    ^
                                    |
                                    |
                                 ^协议

现在感觉，最大的困难是：
1、抽象基类
2、如何在这种不同功能的类如何协调工作。
如何决定哪种类包含其他种类的类
比如：
a、通道一个类
b、设备一个类（具体的通讯设备）
c、协议一个类
它们之间如何简洁有效的协调工作.

3、如何达到最大的复用。

Author: skyjacker Time: 2007-5-22 13:10

从图中可以看出：
界面、协议、通道完全隔离。

自动化控制流程需要界面配置，
自动化控制流程负责将相关的协议发往通道。
当然，自动化控制也不需要知道使用何种通道。

假如来了一个新的需求，也许只需要修改其中的某一或几部分就行了。

对于协议插件的实现，还需要进一步的学习、实践。

Author: Passion Time: 2007-5-22 13:12

CVSTracNT的消息通知部分，就是使用的类似的插件机制，插件负责具体的通知，如Email，msn甚至QQ等。

Author: kendling Time: 2007-5-22 15:16

强！没详细看，有空再详细研究研究。

Author: zzzl Time: 2007-5-22 15:44

貌似很复杂的样子，等你写完我再看

Author: skyjacker Time: 2007-5-22 15:49

这个问题是没有结束的...

Author: kendling Time: 2007-5-22 16:08

哈，那等你结束再看啰。

Author: zzzl Time: 2007-5-22 20:01

你可以写到2008年，不急不急

Welcome to CnPack Forum (http://bbs.cnpack.org/)