设计模式项目实战--命令模式

开通博客已经很多年了，习惯性的看别人写的技术博客，自己确从来没有写的打算。原因有两种，一是觉得写一篇好的博客确实要花费很多时间，时间=金钱吧，毕竟不是啥大师，能够做到信手拈来。二是觉得才疏学浅，写的博客有问题，怕被人拍砖，毕竟技术人员嘛，不会忽悠，有的就是自己这几年敲代码的经验，被人鄙视后，总会觉得自己一无是处吧。

不过最后还是觉得开始养成写博客的习惯，毕竟项目一个个做了，总想有点念想，将自己这几年项目的中用到的设计模式，软件架构之类的东西，总结一下。本人主要是.NET和java开发，今后也会陆陆续续把积累商业项目的工具包源码传到github上去。供大家参考吧。

 

这次谈一下设计模式中的命令模式。命令模式是一个高内聚的模式，其定义为：Encapsulate a request as an object, thereby letting you parameterizeclients with different requests, queue or log requests, and support undoableoperations.（参考-设计模式之禅）。命令模式的通用类图如下所示：

对于命令模式的理解， 以及该模式的优点以及缺点，.NET大家可以参看《大话设计模式》，java人员参考《设计模式之禅》。这里就不多谈了。这里主要谈一下该模式在自己做过的几个项目中是怎样运用的。

 

1.1 业务场景：

由于项目需要，本人需要开发一个CS架构的服务器端程序，完成的功能是实现前端传感器的数据的采集入库。通讯方式是采用串口通讯，实现ms级数据的刷新。那好问题来了。

第一：虽然都是串口通讯，但是前端传感器种类不一，存在多种传感器。熟悉硬件的都知道，不同类别的传感器串口协议不一样，导致解析肯定不一样。以下是一个典型串口协议字段定义图。

 

同步 （SYNC）	起始 （STX）	数据长度 (LEN)	指令 (CMD)	数据体 (DATA)	校验 (CRC)
1byte	1byte	1byte	1byte	最大 252byte	2byte
		数据长度（LEN）

 

第二：系统还需考虑后续新类型的传感器接入，所以对于系统扩展性要求较高

第三：要实现ms级的数据刷新。

 

1.2整体架构

         服务器端：以windowsservice的形式注册到系统中，实现一个后台对于前端传感器数据采集、解析、入库的功能。

         客户端：采用remoting技术，从服务器端获取传感器信息，在客户端上显示。

  1.3命令模式的应用实例

 

1.3.1 串口通讯类

既然是要从串口读取数据，当然要有串口通信类了哦。以下是串口通讯类

这个类没什么好说的，主要就是一些串口的操作，值得一提的是事件onReceiveMessage。这个事件的调用是在串口收到数据的时候调用。该部分的初始化工作如下：

   stringCMportNumber =ApplicationProperties.CMportNumber;

    intCMdataBits =ApplicationProperties.CMdataBits;

    int CMbaudRate=ApplicationProperties.CMbaudRate;

    intCMpacketSize =ApplicationProperties.CMpacketSize;

serialPort0 = newCommSerialPort(CMportNumber, CMbaudRate,CMdataBits,CMpacketSize);

    ITerminalcmSensorTerminal =newCMSensorTerminal();

    serialPort0.onReceiveMessage += new CommSerialPort.onMessageHandle(cmSensorTerminal.ReviveData);

CMSensorTerminal即是我们的众多传感器中的一种，暂且叫做CM传感器

1.3.2双队列缓存方式实现数据上传入库

 

以上则完成了串口类的初始化工作，并且将传感器CM的监听事件（ReceiveData）注册上去，只要该串口有数据传入，及调用该CMSensorTerminal类得ReceiveData函数，进行解析，可能有人会说既然都接送到了数据，那我们直接在receiveData函数里面直接解析数据，然后Insert到数据库不就行了吗？这样是不行的，现实中我们传感器采集要求是ms级的，直接采用进行ADO的操作是不行的，联想到操作系统的消息队列，那好，我们采用双队列的模式，进行处理。这里我们引入DataHandlerThread类，

这个后台线程类维护了2个队列，一个是receiveCommand队列，另外一个是processCommand队列，这个类的功能即是不断的将receiveCommand队列的命令，推送到processCommand队列中去（注意加锁），这里的命令即是我们不同类传感器数据的插入命令。这个类扮演的即是一个缓存的角色，将大量的传感器入库命令先传入receiveCommand队列，然后在推入processCommand队列。

第二个类是dataprocessThread类

这个类得主要功能，即是将processCommand队列中的命令提取出来，进行入库处理。真实的入库处理是在这个类里面直接处理的吗？不是，而是采用命令模式，这个类扮演的是一个invoker的角色，每类传感器都是在其对应的dataprovider里面进行处理的。例如CMCommand传感器，对应于CMSensorProvider（对应命令模式里面的receiver）

总结：再看最后我们解决了三个业务问题了吗？

1.      新类型传感器的扩展

只需继承TerminalCommand，编写该传感器的dataprovider类，在该类里面进行DAO操作即可，做到对修改封闭，对扩展开放的原则。无所修改现有代码

2.      毫秒级刷新

在datahandler类里面，只需创建多个dataprocessThread类，开启多个线程对于同一命令队列进行处理即可。

3.      不同串口协议的解析

由于命令模式对命令的扩展很方便，所以上述问题完成可以在Command中得到解决

 

Ps：可能有人说串口太简单了吧？搞这么麻烦，大家仔细注意下，主要把串口类改成socket操作类，我们就可以实现了基于socket操作的服务器端了，后续command，receiver，invoker（双队列处理）架构完全可以不变。实际项目中可正是这样做的。

代码太多，就没有贴了，稍后给出github地址，上传的都是实际商业项目中的干货，给大家分享                                                                                                                ---Predator.Zhang