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



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

流程简介

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



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

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

           

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

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

/// <summary>
/// 服务流程状态枚举
/// </summary>
public enum MaintanStateEnum
{
non_assign, //已创建,待分配
non_accept, //已分配,待接收
maintaining, //已接收,服务中
non_confirm, //完成服务,待确认
non_userConfirm, //已确认,待客户确认
nonfeedback, //客户已确认,待回访
feedbacked, //回访完成,流程结束
goback //退回分配,此为动作,为了方便编码,不对应服务状态
}


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

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



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

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

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

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



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

适用场景:

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

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

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

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

下面来看看实现:

/// <summary>
/// 维修服务 处理器-抽象基类
/// </summary>
public abstract class ServiceHandler
{
protected ServiceHandler nextHandler;

public virtual void Handle(MaintenanceForm maintenanceForm, object otherParams)
{
if (nextHandler!=null)
{
nextHandler.Handle(maintenanceForm, otherParams);
}
}

}


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

创建:

 /// <summary>
/// 创建服务单流程–应对接线员/服务接收员角色【或者其他具有创建权限的其他角色】
/// </summary>
public class CreateHanlder:ServiceHandler
{
public override void Handle(MaintenanceForm maintenanceForm, object otherParams)
{
//如果已创建(未分配)
if (maintenanceForm.CurrentState==MaintanStateEnum.non_assign)
{
//创建该服务单

return;
}
else //已分配,则传递给下一个流程(假定为分配流程)
{
base.Handle(maintenanceForm,otherParams);
}
}

//设置下一个处理流程
public ServiceHandler NextHandler
{
set
{
base.nextHandler = value;
}
}
}


分配:

/// <summary>
/// 服务流程之分配流程–应对服务处长等分配人员角色【或其他具有分配权限的人员】
/// </summary>
public class AssignHandler:ServiceHandler
{
public override void Handle(Model.MaintenanceForm maintenanceForm, object otherParams)
{
//如果当前处于已分配(未接收)状态
if (maintenanceForm.CurrentState == MaintanStateEnum.non_accept)
{
//进行分配

//记录日志
Log(maintenanceForm);
return;
}
else
{
//进入下一流程
base.Handle(maintenanceForm,otherParams);
}

}

public ServiceHandler NextHandler
{
set
{
base.nextHandler=value;
}
}


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

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

//初始化服务流程链
static ServiceHandler InitServiceChain()
{
//此处应用责任链模式,这样对维修服务单处理的入口只有一个
//根据当前的服务所处的状态可以导向到特定的处理流程【流程为链式】

CreateHanlder createHandler = new CreateHanlder();
AssignHandler assignHandler=new AssignHandler();
FinishHandler finishHandler=new FinishHandler();
FeedbackHandler feedbackHandler = new FeedbackHandler();

//显式指定流程链
/ 注:此处体现流程可增减,可配置【例如写入配置文件】
/
createHandler.NextHandler=assignHandler;
assignHandler.NextHandler=finishHandler;
finishHandler.NextHandler = feedbackHandler;
feedbackHandler.NextHandler = null;

//返回流程启示,类似一个链表结构的头部指针
return createHandler;
}


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

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

static void Main(string[] args)
{
ServiceHandler serviceHandler = InitServiceChain();
//应用场景:

//场景一【演示创建服务单流程】
//点击新增按钮,弹出窗口,创建维修服务表单
MaintenanceForm newMaintenanceForm=new MaintenanceForm();
newMaintenanceForm.Creator = "yh";
newMaintenanceForm.CreatedTime = DateTime.Now;
newMaintenanceForm.CurrentState = MaintanStateEnum.non_assign;

serviceHandler.Handle(newMaintenanceForm,null); //创建

//场景二【演示分配流程】
//在未分配维修单列表中选择一条维修单,点击分配
MaintenanceForm maintenanceForm = new MaintenanceForm();
maintenanceForm.LastModifiedTime = DateTime.Now;
maintenanceForm.CurrentState = MaintanStateEnum.non_accept;

serviceHandler.Handle(maintenanceForm,null); //创建(跳过)->分配

//场景三【演示已分配被维修人员退回,重新分配流程】
//在被退回维修单列表中选择一条维修单,点击分配/重新分配
maintenanceForm.LastModifiedTime = DateTime.Now;
maintenanceForm.CurrentState = MaintanStateEnum.goback;

serviceHandler.Handle(maintenanceForm,null); //创建(跳过)->分配

//场景四【演示接受流程】
//在已分配待完成表单中,选择一条记录,点击接受任务按钮
maintenanceForm.LastModifiedTime = DateTime.Now;
maintenanceForm.CurrentState = MaintanStateEnum.maintaining;

serviceHandler.Handle(maintenanceForm,null); //创建(跳过)->分配(跳过)->接受

//场景五【演示回访流程】
//在已完成待回访表单中,选择一条记录,点击完成回访按钮
maintenanceForm.LastModifiedTime = DateTime.Now;
maintenanceForm.CurrentState = MaintanStateEnum.feedbacked;

serviceHandler.Handle(maintenanceForm,null); //创建(跳过)->分配(跳过)->接受(跳过)……->回访

Console.Read();
}


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

serviceHandler.Handle(maintenanceForm,null); 


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

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

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

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

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

/// <summary>
/// 日志记录策略抽象类
/// </summary>
public abstract class LogStrategy
{
public abstract void Log(Object obj);
}


/// <summary>
/// 数据库策略–服务日志记录实现类
/// </summary>
public class ServiceDatabaseLogStrategy:LogStrategy
{
public override void Log(Object obj)
{
if (obj == null)
{
throw new NullReferenceException("obj");
}

MaintenanceForm maintenanceForm = obj as MaintenanceForm;
//插入数据库
Console.WriteLine("数据库日志记录");
Console.WriteLine();
}
}


/// <summary>
/// E-mail策略–服务日志记录实现类
/// 某些不关注细节的角色
/// (比如领导,他们只关注结果,但他们需要宏观的把握,那么在完成服务步骤,日志可以通过email发送到领导邮箱)
/// </summary>
public class ServiceEMailDatabaseLogStrategy:LogStrategy
{
public override void Log(object obj)
{
if (obj==null)
{
throw new NullReferenceException("obj");
}

MaintenanceForm maintenanceForm = obj as MaintenanceForm;
//发送到指定邮箱操作
Console.WriteLine("email日志记录");
Console.WriteLine();
}
}


/// <summary>
/// 平面文件策略–服务日志记录实现类
/// 可以支持文本文档或者XML文档,便于查看和交互
/// </summary>
public class ServiceFileDatabaseLogStrategy : LogStrategy
{
public override void Log(object obj)
{
if (obj==null)
{
throw new NullReferenceException("obj");
}
Console.WriteLine("文件日志记录");
Console.WriteLine();
}
}


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

/// <summary>
/// 维修服务 处理器-抽象基类
/// </summary>
public abstract class ServiceHandler
{
protected ServiceHandler nextHandler;

public virtual void Handle(MaintenanceFormmaintenanceForm, object otherParams)
{
if (nextHandler != null)
{
nextHandler.Handle(maintenanceForm, otherParams);
}
}

public virtual void Log(MaintenanceFormmaintenanceForm)
{
//记录入数据库

}
}


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

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

public classCreateHanlder:ServiceHandler
{
public override voidHandle(MaintenanceForm maintenanceForm, object otherParams)
{
//如果未分配
if(maintenanceForm.CurrentState==MaintanStateEnum.non_assign)
{

//记录日志
Log(maintenanceForm);
return;
}
else //已分配,则传递给下一个流程(假定为分配流程)
{
base.Handle(maintenanceForm,otherParams);
}
}

//设置下一个处理流程
public ServiceHandler NextHandler
{
set
{
base.nextHandler = value;
}
}

public LogStrategy LogStrategy { get;set; }

public override void Log(MaintenanceFormmaintenanceForm)
{
//如果没有显式指定日志记录策略,则调用基类记录方法【存入DB】
if (LogStrategy == null)
{
base.Log(maintenanceForm);
}
else
{
LogStrategy.Log(maintenanceForm);
}
}
}


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

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

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

static ServiceHandlerInitServiceChain()
{
//此处应用责任链模式,这样对维修服务单处理的入口只有一个
//根据当前的服务所处的状态可以导向到特定的处理流程【流程为链式】

CreateHanlder createHandler = newCreateHanlder();
AssignHandler assignHandler=newAssignHandler();
FinishHandler finishHandler=newFinishHandler();
FeedbackHandler feedbackHandler =new FeedbackHandler();

//显式指定流程链
/
注:此处体现流程可增减,可配置【例如写入配置文件】 /
createHandler.NextHandler=assignHandler;
assignHandler.NextHandler=finishHandler;
finishHandler.NextHandler =feedbackHandler;
feedbackHandler.NextHandler = null;

//显式指定日志的记录策略
/ 支持多种日志记录策略(包括DB、Email、File)
如果不配置,缺省记录方式为DB
此处体现可配置性–某些高层只关注结果 (也就是说可能他们只关注‘服务完成’流程,那么该流程的日志记录策略就可以设置为email)
配置同样可以写入配置文件,也可支持一个流程多种日志记录方式
/

//日志记录策略示例:
createHandler.LogStrategy = newServiceDatabaseLogStrategy(); //DB
assignHandler.LogStrategy = newServiceFileDatabaseLogStrategy(); //File
finishHandler.LogStrategy = newServiceEMailDatabaseLogStrategy(); //email
feedbackHandler.LogStrategy = newServiceEMailDatabaseLogStrategy(); //email

//返回流程启示,类似一个链表结构的头部指针
return createHandler;
}


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

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

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

看看实现:

/// <summary>
/// 命令接口–可以支持:撤消/重做 操作
/// </summary>
public interface ICommand
{
//object Undo();

object Execute();

//object Redo();
}


命令实现:

/// <summary>
/// 实现创建服务任务单命令–Command模式
/// </summary>
public classCreateMaintenanceFormCommand:ICommand
{
private MaintenanceFormmaintenanceForm;
publicCreateMaintenanceFormCommand(MaintenanceForm _maintenanceForm)
{
maintenanceForm = _maintenanceForm;
}

public object Execute()
{
//string str="insertinto….";
//DB.ExecuteNonQuery(….);
return null;
}
}


/// <summary>
/// 分配维修任务命令实现
/// </summary>
public classAssignMaintenanceFormCommand:ICommand
{
private MaintenanceFormmaintenanceForm;
publicAssignMaintenanceFormCommand(MaintenanceForm _maintenanceForm)
{
maintenanceForm = _maintenanceForm;
}

public object Execute()
{
//throw new NotImplementedException();
return null;
}
}


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

public classCreateHanlder:ServiceHandler
{
public override voidHandle(MaintenanceForm maintenanceForm, object otherParams)
{
//如果未分配
if(maintenanceForm.CurrentState==MaintanStateEnum.non_assign)
{

//构造创建服务单命令,并执行
ICommand createCommand = newCreateMaintenanceFormCommand(maintenanceForm);
createCommand.Execute();

//记录日志
Log(maintenanceForm);
return;
}
else //已分配,则传递给下一个流程(假定为分配流程)
{
base.Handle(maintenanceForm,otherParams);
}
}


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

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

总结

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



版权声明:本文为博主原创文章,未经博主允许不得转载。