一讲到工作流，很多人第一反应就是这个东西很深奥，有时候又觉得离我们较为遥远，确实完善的工作流设计很多方面，而正是由于需要兼顾很多方面，一般通用的工作流都难做到尽善尽美。微软也提供了几个版本的WF框架支持，也有一些厂家是基于这个框架基础上开发的工作流应用。
以前由于项目的需要，参与过一些工作流的项目开发，其中有些是基于我简易工作流的原理上进行拓展的，包括一个广州市各区县使用的行业审批业务平台，由于基于自己的流程处理，界面设计、流程流转等方面可以很好符合客户需求，定制的弹性较好，缺点是不够通用，也需要编写表单部分代码。
后面由于业务的需要，工作流方面的业务逐渐显得迫切，公司是想采用一个较为通用工作流框架来组织目前的业务，因此找了广州一家做工作流的公司，购买了他们的产品，虽然号称完全通过后台配置，零代码实现工作流业务表单的处理，但是由于客户对表单的设计要求比较多，有时候需要结合一些外部的数据接口，流程处理方面也有着进一步的需要，这样可能就打破了他们原来的格局，导致无论在表单设计、流程配置等方面，都需要购买他们工程师的现场服务，来进一步完善整个项目的内容，导致整个项目进展缓慢，遭遇水土不服的处境。
因此感觉，一个工作流模块，号称再强大，如果不能很好结合项目应用，即使零代码的功能配置，也可能使你处于尴尬的境况之中，因为通过配置，可能在代码里面平常很容易实现的表单功能，要通过零代码配置，花费的时间更多更难掌握，因为零代码是有代价的，需要您很好利用他们的API，他们的业务对象，有时候还需要很曲折的摸索参数，而这一切可能就是非常致命的弱点。

1、简易工作流的设计模型

在没有第三方工作流模块的情况下，简易工作流就是利用数据库和业务对象之间的协作关系，构建的一个半模块化的流程引擎，它能通过整合到项目代码中进行更好的融合以便实现工作流的相关功能。
首先我们知道，我们在Office里面创建任何文档，都有一个模板的概念，这样我们方便利用一些现成的数据和布局，工作流也一样，有一个流程模板的概念，如下所示。

然后每个流程模板，本身会预定义了一系列的处理流程，以便在流程实例里面进行不同的处理，因此流程模板还包含了多个流程步骤对象，他们的关系构成如下。

每个流程实例，除了他们自己的流程数据和字段信息外，它本身还有一个表单设计的问题，如费用审批，可能包含填写的费用清单数据等，所以流程实例还应该包含了流程的业务表单对象。
这样他们构成了一个完整的流程业务对象关系，如下所示。

2、流程审批的操作

对于一个流程处理操作，我们知道一般有审批通过、拒绝、退回到某步骤、转发到内部阅读、阅读，以及包括起草者能撤销表单呢等操作，当然如果还有一些具体的业务，可能还会有一些流程的处理才操作，不过基本上也可以归结为上面几种，只是他们每步处理的数据内容不同而已。因此审批的操作步骤分类如下所示。

这些操作我们都可以通过一些界面操作的封装实现，因为他们基本上都是通用的，我们传入一些流程ID等相关标识后，就能交给这些标准的操作界面完成了。
如审批界面如下所示，里面包含了通过、拒绝，跳回到某步骤，增加步骤等功能集合。

上面的界面是审批过程中，对于某一个流程处理人员实现的操作，而有时候，我们可能需要针对多个人进行某个步骤的处理，如传递给内部人员进行分阅操作，那么就应该选定多个人员进行处理，大概的处理界面效果如下所示。

当然，若申请人的申请单填写错误，需要撤销的话，那么也应该有这个操作，撤销表单后，就可以重新填写表单，然后再次提交进行流程。

3、流程审批的表单处理

在表单的动态设计和显示方面，一直没有好的思路，因此我觉得把流程模块作为半模块化即可，把部分界面通过代码编写方式进行整合，因此把表单的填写，表单查看做到用户控件里面，然后在界面里面引用即可。
如下面的表单填写操作界面如下所示，对不同的流程表单，在项目中增加一个表单的填写界面和保存操作即可。

查看并处理的表单操作，我们可以先做一个查看表单信息的界面，然后整合流程的处理工具栏，组合成一个查看、处理操作一体化的流程操作。

当然，如果是能够有动态设计表单，然后进行无缝整合当然更加完美，不过这样的操作，界面设计上也不会很麻烦，一般普通的开发人员都能胜任，因此，对于其他流程表单，依葫芦画瓢就可以完成不同的表单了。
而且里面的工具栏代码都是可以操作的，虽然可能集成了不同业务的处理方式，但是我们还是动态进行处理，处理代码如下所示。

private void InitToolBar()
{
    //如果流程是可以撤销，且表单状态为处理中，那么可以“撤销”操作可用
    bool mayCancel = BLLFactory<AppApply>.Instance.IsApplyMayCancel(ApplyId, base.LoginUserInfo.ID);
    this.btnCancel.ToVisibility(mayCancel);

    //可退回重新编辑
    bool mayBackToEdit = BLLFactory<AppApply>.Instance.IsApplyMayBackEdit(ApplyId, base.LoginUserInfo.ID);
    this.btnEdit.ToVisibility(mayBackToEdit);

    //判断是否需要显示阅办状态
    bool isReadStatus = BLLFactory<ApplyRead>.Instance.IsReadSatus(ApplyId, base.LoginUserInfo.ID);
    this.btnRead.ToVisibility(isReadStatus);

    //如果不是当前审批人隐藏审批按钮
    bool canDeal = BLLFactory<BLL.ApplyUser>.Instance.IsCheckPermission(ApplyId, base.LoginUserInfo.ID);
    if (canDeal)
    {
        ApplyFlowInfo flowInfo = BLLFactory<ApplyFlow>.Instance.GetFirstUnHandledFlow(ApplyId);
        if (flowInfo != null)
        {
            string procTypeName = BLLFactory<AppProc>.Instance.GetProcType(flowInfo.ProcType);
            BarButtonItem button = new BarButtonItem();
            button.Caption = procTypeName;
            button.Name = procTypeName;
            button.Tag = flowInfo;//绑定流程内容
            button.ImageIndex = 3;
            button.LargeImageIndex = 3;
            button.PaintStyle = BarItemPaintStyle.CaptionGlyph;
            button.ItemClick += new ItemClickEventHandler(button_ItemClick);
            this.bar1.AddItem(button);
        }
    }
}

上面对于流程步骤的处理，就交给一个独立的按钮事件进行判断处理即可，根据不同的业务步骤名称进行不同的处理，这样就能够进行很好的控制处理。