现在的位置: 首页 > 综合 > 正文

浅谈简单工作流设计——责任链模式配合策略与命令模式的实现

2013年06月13日 ⁄ 综合 ⁄ 共 9629字 ⁄ 字号 评论关闭

本文以项目中的一个工作流模块,演示责任链模式、策略模式、命令模式的组合实现!

流程简介

最近在做的一个项目,涉及到的是一个流程性质的需求。关于工程机械行业的服务流程:服务任务流程和备件发运流程。

项目之初,需求不是很清晰,算是演化模型吧。先出一个简单版本,然后根据用户的使用情况,再进一步探测新需求。所以也就是说这两个流程中的每一步暂时都不是固定的,而应该是可配置、可增减的。

目前暂定的两个流程示意图如下:

           

以上为两个流程的大致过程,当然实际过程中,可能还要走其他的流程。

但是,仔细分析,你会看到。不管有多少个中间步骤,它们始终都对应着它们在该流程中所处的状态:


你会看到non_后面跟的都是一个个动作。在这里分清状态和动作是很重要的,不然就很难理清了。还有有时一个动作对应着前后状态,不要出现重复的状态比如:created(创建完成)和non_assign(待分配)在这里就是所谓的重复状态。

这些状态其实就是贯穿着整个流程的主线,类似于一个城市的主干道一样。我们只要抓着这样一天线索来思考,就能够化繁为简。

每个步骤可配置,各个步骤不相耦合,实现调用端一致性——责任链模式

而责任链模式,正是为此而生的!

在这里,我采用了责任链模式来封装这种步骤的不确定带来的变化。

首先我们有必要先了解一下,什么是责任链模式:

职责链模式(Chain of Responsibility):使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。

适用场景:

1、有多个的对象可以处理一个请求,哪个对象处理该请求运行时刻自动确定;

2、在不明确指定接收者的情况下,向多个对象中的一个提交一个请求;

3、处理一个请求的对象集合应被动态指定。

 可以看到无论是上面哪种场景,都存在一个多对一的关系。在这个流程中,一很明显对应着服务流程(说白了就是数据库服务任务的一条记录)。大部分情况下,我们都在完成对一条服务中相关字段的修改,同时置不同的服务状态。而多,在这里应该对应着不同的步骤。

下面来看看实现:


这是一个抽象处理器,流程中每个步骤的处理器,会覆写这个处理器的处理方法:

创建:

分配:


其他流程我就不一一贴出代码。下面来分析一下以上这几个处理器,有什么特别之处。首先,我们看出了,它是以状态为导向的(在Handle方法的判断中)。每个步骤都有一个NextHandler属性,用来配置下一个处理器,这就可以串联他们到一个流程中。大家可以看到每个Handle方法最后都有一个"return;"语句。没错,这里我使用了不完整的责任链模式。也就是一个流程不是一次走结束的,因为它们可能不是一个时间上的连贯,也可能不是一个人走完所有的流程,比如某人负责创建任务单,某人负责分配等。

下面看看,如何来串联他们到一个流程中:


上面中第二大代码块,即实现了所有处理器的拼装与整合(只是示例,并不完整)

下面我们来看看客户端调用:


无论走哪个流程,整个的调用方法只有一个:


第一个参数为任务的实体,第二个为附带参数(如果没有,可不必传递)。在任务实体会在流程链中传递,实体中当前状态会指引它交给哪个Handler处理。这样无论你流程中步骤如何变化,在调用端的调用方式都是唯一的。而且你增减步骤对其他流程都不产生任何影响,唯一需要改变的就是组装他们的地方。比如,你需要在创建完服务单之后,走一个审核流程,那么增加它就是一个非常简单的动作。

这里关于发运流程的做法我就不多举例子了,大同小异。

实现每个步骤不同的日志记录方式之——策略模式

这里可能会对日志的记录有多种需求,比如发送Email给远端工程师或者某些领导等,存入数据库或平面文件备份.....

策略模式的细节就不多做介绍了,看实现:





上面就是暂定的几个日志记录策略的实现,下面看看如何将它们组合到各个处理器中。首先,其实刚才处理器的抽象基类是有一个记录日志的虚方法的:

上面的抽象类实现的是,默认记录入数据库

其实,每个步骤的处理器中也都存在日志记录的处理(只是为了不干扰讲解责任链,而省略了)

这里有一个LogStrategy(日志策略基类)类型的属性,用来对外提供配置接口。每个处理器类都覆写了处理器基类的Log方法,逻辑为:如果有日志记录策略,则以日志记录策略来记录,否则用基类的记录方式(DB方式)。

上面在Handle方法返回之前,调用了被覆写的Log方法。

下面看看,外面是如何组装日志记录策略的:

可以看到在组装流程的时候我们同时组装了日志记录的策略。事实上,这里每个流程只对应了一种策略,当然可以为一个流程配置几个日志记录策略啦(修改为List<LogStrategy>,然后在处理器的Log方法中依次调用)。

处理数据库处理逻辑调用端的一致性——命令模式

不知道大家平时是否都习惯了用三层架构来应对一般项目。在我们的项目中,BLL层是一个傀儡这是一个事实(不对此进行辩论,无论你的是不是,反正我们的项目是了,至于对与错,大家心里都明白)。这里,我一改往日数据库操作调用端采用的各种繁杂的XXXBLL.XXX()的不一致性。改为采用了命令模式来实现对数据库的增改删查。至于理由——业务都由各个处理器实现,没有采用BLL形式的必要。同时我的数据库操作方法的调用端一直,修改就封装在内部。

看看实现:

命令实现:

且看创建服务单处理器中,如何调用:

参数都是,各个命令的构造方法传入,所以有灵活性。额外的参数,来自Handle方法的otherParams,所以参数传递没有产生限制。

当然,这里没有实现命令的撤销与重做。

总结

以上就是该服务流程所采用的三种设计模式——责任链模式、策略模式、命令模式。对设计不精,但是很有兴趣。这是我的一些想法,我觉得在大家设计一些简单工作流或者流程性质很强的需求的时候,能够有一定的指导意义!

抱歉!评论已关闭.