1

我正在尝试让我的 Windows 状态机工作流程与最终用户进行通信。我试图在 StateActivity 中实现的一般模式是：

StateInitializationActivity：向用户发送请求回答问题的消息（例如“您批准此文档吗？”），以及...的上下文...
...EventDrivenActivity：处理用户发送的答案
StateFinalizationActivity：取消消息（例如文件被撤回，不再需要批准）

如果 StateActivity 是“叶状态”（即没有子状态），这一切都可以正常工作。但是，如果我想使用状态的递归组合，它就不起作用。对于非叶状态，StateInitialization 和 StateFinalization 不会运行（我通过使用 Reflector 检查 StateActivity 源代码确认了这种行为）。EventDrivenActivity 仍在监听，但最终用户不知道发生了什么。

对于 StateInitialization，我认为解决此问题的一种方法是将其替换为 EventDrivenActivity 和零延迟计时器。我对如何处理 StateFinalization 感到困惑。

那么 - 是否有人对如何让状态最终确定活动始终运行有任何想法，即使对于非叶状态也是如此？

4

3 回答 3

1

不幸的是，“嵌套状态”的结构是包含“子”的“父”之一，设计器 UI 重新执行了这个概念。因此，以您的思维方式思考是非常自然和直观的。它的不幸，因为它是错误的。

真正的关系是“一般”->“特定”之一。它实际上是一个层次结构的类结构。考虑一个更熟悉的这种关系：-

public class MySuperClass
{
    public MySuperClass(object parameter) { }
    protected void DoSomething() { }
}

public class MySubClass : MySuperClass
{
    protected void DoSomethingElse() { }
}

这里MySubClass继承DoSomething自SuperClass. 上面虽然被破坏了，因为SuperClass没有默认构造函数。的参数化构造函数SuperClass也不是由SubClass. 事实上，从逻辑上讲，子类永远不会继承超类的构造函数（或析构函数）。（是的，默认构造函数有一些神奇的连接，但糖比物质更多）。

类似地，包含的 StateAivities 与另一个之间的关系StateActivity实际上是包含的活动是容器的特化。每个包含的活动都继承了容器的一组事件驱动活动。但是，每个包含的 StateActivity 都是与任何其他状态相同的工作流中的第一类离散状态。

包含的活动实际变成了一个抽象，它不能被转换到，重要的是没有转换到另一个状态“内部”的状态的真正概念。通过扩展，也没有离开这种外部状态的概念。因此，包含的 StateActivity 没有初始化或完成。

设计器的一个怪癖允许您添加 StateInitialization 和 StateFinalization 然后将 StateActivities 添加到状态。如果您以相反的方式尝试，设计器不会让您这样做，因为它知道初始化和终结将永远不会运行。

我意识到这实际上并不能回答你的问题，在这种情况下我不愿意说“它不能完成”，但如果可以的话，它会有点笨拙。

于 2009-11-25T18:33:54.517 回答
0

I've thought of another way of solving the problem. Originally, I had in mind that for communications I would use the WCF-integrated SendActivity and ReceiveActivity provided in WF 3.5.

However, in the end I came to the conclusion that it's easier to ignore these activities and implement your own IEventActivity with a local service. IEventActivity.Subscribe can be used to indicate to users that there is a question for them to answer and IEventActivity.Unsubscribe can be used to cancel the question. This means that separate activities in the State's inialization and finalization blocks are not required. The message routing is done manually using workflow queues and the user's response is added to the queue with appropriate name. I used Guid's for the queue names, and these are passed to the user during the IEventActivity.Subscribe call.

I used the 'File System Watcher' example in MSDN to work out how to do this. I also found this article very insructive: http://www.infoq.com/articles/lublinksy-workqueue-mgr

于 2010-01-29T16:29:49.173 回答
0

好的，这就是我最终决定做的事情。我创建了一个自定义跟踪服务，它查找与进入或离开与最终用户通信相关的状态相对应的活动事件。该服务在进入状态时将用户的决策输入数据库，并在状态离开时将其删除。用户可以查询数据库以查看工作流正在等待哪些决策。工作流使用 EventDrivenActivity 中的 ReceiveActivity 侦听用户响应。这也适用于父“超级州”中的决策。这可能不完全是“跟踪服务”的用途，但它似乎有效

于 2009-12-09T15:54:53.127 回答