自己对WWF的理解。

[lieying1946]

我几个月前的理解：在Workflow中的每个节点中定义大量业务逻辑，以后要改就得在Workflow中大改很困难。


我现在的理解： 根据工作流中的状态来控制流程，查找当前工作流的状态，返回当前工作流（发起的一个单） 可以执行的状态，
根据这个状态字符串，来控制哪些功能（事件）当前可以执行，当执行某个功能（事件，操作）时，更新工作流状态到下特定的一个状态， 从而让一个数据按 Workflow中画的流程 走完整个步骤。

[以专业开发人员为伍]

不用wwf，不知道它的设计思路和限制。

[以专业开发人员为伍]

[Quote=引用楼主 的回复:]
我现在的理解： 根据工作流中的状态来控制流程，查找当前工作流的状态，返回当前工作流（发起的一个单） 可以执行的状态，
根据这个状态字符串，来控制哪些功能（事件）当前可以执行，当执行某个功能（事件，操作）时，更新工作流状态到下特定的一个状态， 从而让一个数据按 Workflow中画的流程 走完整个步骤。
[/Quote]

就一般的工作流概念来说，你的这个理解显然是错误的。一个工作节点是上一个节点的后继，这就好像是一张张“工单”，它有一部分字段是从上一张工单那里复制来的，但是也有自己独特的新字段。最主要地，它是一个新的工单实体，而不是仅仅是什么“状态字符串”。

因此一份工单，它自身的具体实体类型，以及它内部有只想“上一个工单实体的编号”，这两项就是它的状态。不需要什么“状态字符串”。

[以专业开发人员为伍]

以及它内部有只想“上一个工单实体的编号” --> 以及它内部有属性指向“上一个工单实体的编号”


我们可以想象一下，每一个工作流（我说的是具体执行时）都可能有分支，也可能有循环。比如说前两天下大雨，那么排水公司来抢修了，一般的抢修任务就按照一般的流程执行，但是有一个地点涉及到重要设施，于是就要临时打电话到指挥中心去协调另外一个重要部门的技术人员先来勘测、然后才敢指定抢修计划。那么应急指挥系统要自动记录这个工作流，就是把排水公司的工单保存起来，然后自动判断这个工单上的几个字段值，然后自动就把下一个工单发送给另外一个重要的部门的值班人员了！

而这是一个复杂的系统，这里的“其它部门”可能涉及几十个部门的几百个不同的科室、人员，而且要求灵活定义。因此这些“字段值”，不要僵化地搞什么“状态字符串”那种低级的东西。而应该是根据自然的工单需求自定义的字段。只有这样才能方便地表达流转条件。

假设你搞一个“状态字符串”来给工作流系统作为流程控制，我看是“死路一条”。

如果是

[devmiao]

[Quote=引用楼主 的回复:]
我几个月前的理解：在Workflow中的每个节点中定义大量业务逻辑，以后要改就得在Workflow中大改很困难。


我现在的理解： 根据工作流中的状态来控制流程，查找当前工作流的状态，返回当前工作流（发起的一个单） 可以执行的状态，
根据这个状态字符串，来控制哪些功能（事件）当前可以执行，当执行某个功能（事件，操作）时，更新工作流状态到下特定的一个状态， 从而让一个数据按 Workfl……
[/Quote]
你说的是WF框架还是自己设计工作流？如果是WF，你直接用StateMachine工作流就好了。

[lieying1946]

我说的正是 wf3.5 StateMachine工作流

[以专业开发人员为伍]

WF3.5被废弃了。这个问题可以看作是微软.net中最大的问题，但是有毒瘤不得不割掉，不得不换上一个不兼容的新东西。

[lieying1946]

WF3.5并没有被废弃，WF4，WF4.5使用是另一套程序集。

[以专业开发人员为伍]

怪不得你会纠结在“状态字符串”这里！

至少我要告诉你，“状态机”工作流也根本不是什么凭着一个简单的“状态字符串”那种简单的东西，而是要你在设计器上输入一大堆用于判断数据值的源代码！

[lieying1946]

我今天对wf的理解：

WF3 通信机制是 事件 。 可以理解成 是 开发者指定 一系列按照预定 线路(规则)执行的 事件 ，wf3.5使用的事件与host应用程序通讯。

wf4 ，wf4.5通信机制是 bookmark （变量，参数 ）.

[以专业开发人员为伍]

这有点就近了。

你还说它们是一样的么？

[lieying1946]

wf4 wf 4.5 使用的Bookmark 与host应用程序通讯。

[lieying1946]

今天对WF 的理解：

传统asp.net管理系统开发他是以数据库表为中心，为驱动 为思想方向。
而Workflow程序他是以事件为中心为驱动，为思想方向。