Winform开发框架之简易工做流设计

一讲到工做流，不少人第一反应就是这个东西很深奥，有时候又以为离咱们较为遥远，确实完善的工做流设计不少方面，而正是因为须要兼顾不少方面，通常通用的工做流都难作到尽善尽美。微软也提供了几个版本的WF框架支持，也有一些厂家是基于这个框架基础上开发的工做流应用。

之前因为项目的须要，参与过一些工做流的项目开发，其中有些是基于我简易工做流的原理上进行拓展的，包括一个广州市各区县使用的行业审批业务平台，因为基于本身的流程处理，界面设计、流程流转等方面能够很好符合客户需求，定制的弹性较好，缺点是不够通用，也须要编写表单部分代码。

后面因为业务的须要，工做流方面的业务逐渐显得迫切，公司是想采用一个较为通用工做流框架来组织目前的业务，所以找了广州一家作工做流的公司，购买了他们的产品，虽然号称彻底经过后台配置，零代码实现工做流业务表单的处理，可是因为客户对表单的设计要求比较多，有时候须要结合一些外部的数据接口，流程处理方面也有着进一步的须要，这样可能就打破了他们原来的格局，致使不管在表单设计、流程配置等方面，都须要购买他们工程师的现场服务，来进一步完善整个项目的内容，致使整个项目进展缓慢，遭遇水土不服的处境。

所以感受，一个工做流模块，号称再强大，若是不能很好结合项目应用，即便零代码的功能配置，也可能使你处于尴尬的境况之中，由于经过配置，可能在代码里面日常很容易实现的表单功能，要经过零代码配置，花费的时间更多更难掌握，由于零代码是有代价的，须要您很好利用他们的API，他们的业务对象，有时候还须要很曲折的摸索参数，而这一切可能就是很是致命的弱点。

一、简易工做流的设计模型

在没有第三方工做流模块的状况下，简易工做流就是利用数据库和业务对象之间的协做关系，构建的一个半模块化的流程引擎，它能经过整合到项目代码中进行更好的融合以便实现工做流的相关功能。

首先咱们知道，咱们在Office里面建立任何文档，都有一个模板的概念，这样咱们方便利用一些现成的数据和布局，工做流也同样，有一个流程模板的概念，以下所示。

而后每一个流程模板，自己会预约义了一系列的处理流程，以便在流程实例里面进行不一样的处理，所以流程模板还包含了多个流程步骤对象，他们的关系构成以下。

每一个流程实例，除了他们本身的流程数据和字段信息外，它自己还有一个表单设计的问题，如费用审批，可能包含填写的费用清单数据等，因此流程实例还应该包含了流程的业务表单对象。

这样他们构成了一个完整的流程业务对象关系，以下所示。

二、流程审批的操做

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

 

这些操做咱们均可以经过一些界面操做的封装实现，由于他们基本上都是通用的，咱们传入一些流程ID等相关标识后，就能交给这些标准的操做界面完成了。

如审批界面以下所示，里面包含了经过、拒绝，跳回到某步骤，增长步骤等功能集合。

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

固然，若申请人的申请单填写错误，须要撤销的话，那么也应该有这个操做，撤销表单后，就能够从新填写表单，而后再次提交进行流程。

三、流程审批的表单处理

 在表单的动态设计和显示方面，一直没有好的思路，所以我以为把流程模块做为半模块化便可，把部分界面经过代码编写方式进行整合，所以把表单的填写，表单查看作到用户控件里面，而后在界面里面引用便可。

以下面的表单填写操做界面以下所示，对不一样的流程表单，在项目中增长一个表单的填写界面和保存操做便可。

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

固然，若是是可以有动态设计表单，而后进行无缝整合固然更加完美，不过这样的操做，界面设计上也不会很麻烦，通常普通的开发人员都能胜任，所以，对于其余流程表单，依葫芦画瓢就能够完成不一样的表单了。

并且里面的工具栏代码都是能够操做的，虽然可能集成了不一样业务的处理方式，可是咱们仍是动态进行处理，处理代码以下所示。

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

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