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

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

 

流程简介

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

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

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

           

 

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

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

 

/// <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);
           }
       }