WF从入门到精通（第十四章）：基于状态的工作流

WF从入门到精通（第十四章）：基于状态的工作流2010-06-03 cnblogs GuoYong.Che学习完本章，你将掌握：

1.理解状态机的概念以及它怎样被模拟到工作流处理中的

2.创建基于状态的工作流

3.运用初始（initial）和终止（terminal）状态条件

4.使用代码进行状态的切换

在第四章“活动和工作流类型介绍”中，我阐述过你使用WF所能创建的工作流类型，在那里我提到过基于状态的工作流。基于状态的工作流模型被认为是有限自动机（finite state machine）。基于状态的工作流在工作流需要和外部事件进行许多交互的场合中大出风头。在事件触发并被工作流处理的时候，工作流能按要求进行状态的切换。

WF为创建基于状态的工作流提供了富余的开发体验，你迄今为止在本书中看到的许多东西都适用于基于状态的工作流。例如，当一个状态切换过来的时候，假如你想的话，你能去执行几个顺序活动，进行条件判定（使用规则或者代码），或者使用一个迭代活动结构来循环访问一些数据点。唯一真正的区别是活动怎样排队执行。在顺序或并行工作流中，它们以出现的顺序进行排队。但是在基于状态的工作流中，活动以状态切换进出来进行排队。事件通常驱动这些切换过程，但是这条规则不是通用的。让我们再看看状态机的概念并把这些概念和你能使用的WF活动结合起来去构建你的工作流。

状态机的概念

状态机的目的是构建你业务流程中的离散点，切换通过事件来控制。例如，把你的洗衣机接通电源，然后关门并按下启动按钮。按下启动按钮时初始化了一个状态机，它通过运行各种各样的清洁周期来清洗你待洗的衣物直到这些周期全部完成。

状态机有一个已知的起点和一个已知的终点。中间的状态应能通过预期事件的触发去进行控制，但机器总处于一个特定的状态。有时事件把状态机扔进无效的状态中，这种情形和在你的应用程序中维持未处理的异常的情形来说并没有什么不同，整个过程不是忽然停止就是完全崩溃。无论哪种情况，切换到无效状态都是要密切监视的，至少在数字电子系统（digital electronic systems）中是这样。

总的来说，第4章涵盖了涉及状态机的基本概念。可看看“状态活动”这一节快速复习一下。让我们从怎样设计活动转到在基于状态的工作流中怎样使用活动去吧。

使用状态活动

也许你不会太惊讶，在你的基于状态的工作流中State活动构建了一个状态。它是一个组合活动，但它局限于只接受特定类型的活动来作为它的子活动，它们是：EventDriven活动，StateInitialization活动，StateFinalization活动以及其它State活动。EventDriven活动等待（监听）那些将导致切换到另一个状态的事件，而在状态被切换进来和切换出去的时候，StateInitialization和StateFinalization是保证能分别去执行相应处理的活动。对于能拖拽第二个State活动到一个已存在的State活动中去可能看起来有些古怪，但其意图是提供一种在父状态机中嵌入子状态机的能力。

对于你的状态能容纳的那些有效活动的数目也有一个限制。只允许有唯一的一个StateInitialization和StateFinalization，你可以只有其中的一个，但每一个都不能超过一个。它们都不是必须的。

但是并没有说你不能只有一个或者更多的子EventDriven和State活动。事实上，一般都能找到多个EventDriven活动，因为每一个事件可能会导致切换到一个不同的状态。例如，一个“不批准（disapprove）”事件可能会切换到最终的状态（结束状态），而一个“批准（approve）”事件则可能切换到一个预定的状态并要求进行更多的审批。至于State活动，假如你要创建嵌入的基于状态的工作流的话，毫无疑问超过一个也应当是允许的。只有一个状态（切换）的基于状态的工作流构建成了一个简单的顺序工作流，因此在那种情况下你应当直接使用一个顺序工作流。在任何情况下，使用State活动只需从工具箱中拖拽它的一个实例到工作流视图设计器上，唯一的必要条件是工作流自身必须是基于状态的工作流而不是顺序工作流。然后确定你的状态活动应容纳些什么子活动，并按需要把它们拖拽进去，牢记你只能插入四种类型的活动。