本文以项目中的一个工作流模块，演示责任链模式、策略模式、命令模式的组合实现！
流程简介
最近在做的一个项目，涉及到的是一个流程性质的需求。关于工程机械行业的服务流程：服务任务流程和备件发运流程。
项目之初，需求不是很清晰，算是演化模型吧。先出一个简单版本，然后根据用户的使用情况，再进一步探测新需求。所以也就是说这两个流程中的每一步暂时都不是固定的，而应该是可配置、可增减的。
目前暂定的两个流程示意图如下：
以上为两个流程的大致过程，当然实际过程中，可能还要走其他的流程。
但是，仔细分析，你会看到。不管有多少个中间步骤，它们始终都对应着它们在该流程中所处的状态：
/// <summary>
/// 服务流程状态枚举
/// </summary>
public enum MaintanStateEnum
{
non_assign, //已创建，待分配
non_accept, //已分配，待接收
maintaining, //已接收，服务中
non_confirm, //完成服务，待确认
non_userConfirm, //已确认，待客户确认
non_feedback, //客户已确认，待回访
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，所以参数传递没有产生限制。
当然，这里没有实现命令的撤销与重做。
总结
以上就是该服务流程所采用的三种设计模式——责任链模式、策略模式、命令模式。对设计不精，但是很有兴趣。这是我的一些想法，我觉得在大家设计一些简单工作流或者流程性质很强的需求的时候，能够有一定的指导意义
| 
