Statefinalization/initialization活动仅在叶状态上运行

Question

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

StateInitializationActivity:向用户发送消息，请求对问题的回答(例如“您是否批准此文件？”)，以及……的上下文。

...EventDrivenActivity:处理用户发送的答案

StateFinalizationActivity:取消消息(如单据已被收回，不再需要审批)

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

对于StateInitialization，我认为解决这个问题的一种方法是用一个EventDrivenActivity和一个零延迟计时器来代替它。我被困在如何处理StateFinalization上了。

那么，有没有人知道如何让State Finalization活动始终运行，即使对于非叶状态也是如此？

Answer 1

不幸的是，“嵌套状态”的结构是包含“子元素”的“父元素”之一，设计者UI再次强化了这一概念。因此，思考你正在思考的方式是非常自然和直观的。这是不幸的，因为这是错误的。

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

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

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

在这里，MySubClass从SuperClass继承了DoSomething。但是，由于SuperClass没有默认的构造函数，所以上面的内容被破坏了。此外，SubClass不会继承SuperClass的参数化构造函数。实际上，从逻辑上讲，子类永远不会继承超类的构造函数(或析构函数)。(是的，默认构造函数有一些神奇的连接，但这更像是糖而不是实质)。

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

包含的活动actual变成了抽象的，它不能被转换，重要的是，没有真正的概念转换到“在”另一个状态中的状态。由此引出，也不存在离开这种外部状态的概念。因此，不需要对包含的StateActivity进行初始化或完成。

设计器的一个怪癖允许您添加StateInitialization和StateFinalization，然后将StateActivities添加到状态。如果你反其道而行之，设计器不会让你这样做，因为它知道初始化和结束永远不会运行。

我意识到这实际上并没有回答你的问题，我不愿意在这种情况下说“这是不可能的”，但如果它可以的话，它将是有点老生常谈。

Answer 2

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

Answer 3

我想到了解决这个问题的另一种方法。最初，我考虑使用WF3.5中提供的集成了WCF的SendActivity和ReceiveActivity进行通信。

但是，最后我得出的结论是，忽略这些活动并使用本地服务实现您自己的IEventActivity会更容易。IEventActivity.Subscribe可用于指示用户有问题要回答，而IEventActivity.Unsubscribe可用于取消该问题。这意味着在State的初始化和完成块中不需要单独的活动。使用工作流队列手动完成消息路由，并将用户的响应添加到具有适当名称的队列中。我使用Guid作为队列名称，这些名称在IEventActivity.Subscribe调用期间传递给用户。

我使用了MSDN中的“文件系统观察者”示例来了解如何做到这一点。我还发现这篇文章很有启发性：http://www.infoq.com/articles/lublinksy-workqueue-mgr