昨天发了几篇文章,被一些朋友说写的不认真,今天又写了几篇,请各位指点
另承上,今晚随手写一篇[关于工作流的模式]的文章,没有什么技术性,无法归到技术栏里,就当随笔发吧
-------------------------
关于工作流的模式
流模式（Sequential）
1.适合一个比效机械化的流程
2.在这种流程中，参与者处于一种被动的局面，他必须沿设定的路线一步一步完成。
例1:在MIS系统中，一个操作机器的工作流:
（开使->关1闸 –> 关2闸 -> 修理 -> 开2闸-> 开1闸 -> 结束）
在这个工作流中，需要严格按流程操作。而且在[修理]结点处可能还要调用一个修理某类设备的工作流。
例2:比如一个购物的工作流:
(开使->浏览->选择->缴费->取货 -> 结束)
在该例中，流程序顺的严格性就显得不是很重要，比如[缴费]与[取货]结点谁先谁后就不是很重要，只要[缴费]与[取货]都完成了就可以结正常[结束]该流程。
对于像这样的业务需求，就可以使用状态机模式
流模式的执行并非完全是顺序的。它们仍然可以接收外部事件或者启动并行任务，在这种情况下，可能会有状态机模式的表现形式。但就其设计与维护方式来说仍是 流模式
状态机模式(State Machine )
在状态机模式下，参与者的自主性比效大，工作流更多的是一个提醒的作用
例:一个审批流程：有六个部门批准才能通过，这六个部门的审批行为是独立进行的，不受其他部门结果的影响，可以使用状态机模式，配合规则实现
A.六个部门审批行为是并行模式
B.规则可以使用:全票通过，一票通过，简单多数，绝对多数，额定通过，等
另外状态可以由一种进入到另一种，如上例出现平票状态后，将进入联合听证流程
如何选择工作流模式
一个简单的判断标准
影响工作流程的一些重要的选择是否发生在工作流外部？是否由用户进行控制？
如果是，那就不适合采用流模式。而最好选用状态机模式
因为流模式本质上是对工作流的路径建模，将路径信息都编码到了模型之中。但是在某些时候，业务并不关心路径，而只关心结果，并且不关心结果是如何实现的。
这时要用流模式，就需要画出许多复杂的路径流程，但是这些复杂的路径却并非我们所关注的问题。而最后往往是维护路径的付出远远大于维护业务模块。
实际设计中的模式：
在实际设计中，模式的应用并不是泾渭分明的。同一工作流，在不同参与者的眼中就有不同的模式。
如一个请假的工作流，参与都有两种：申请人、审批人
在申请人眼里，他所参与的工作流是[流模式]
在审批人眼里，他所参与的工作流是[状态机模式]
以上是本人在开发各类工作流中的一些心得。在WWF中可能也会有一定的适用性