architecture - 工作流基础设计问题/注意事项？

Question

我正在审查这项技术，但有一些设计问题让我停顿了几次。有人可以帮我整理一下吗？

1) 在工作流中，所有变量都是全局变量或事件变量。如果你想将它们绑定(bind)到事件的输入/输出参数，那么它们将需要在全局范围内。我们都处理过管理持久的、全局范围的变量。

我的另一个担心是，这种全局范围的变量有很大的诱惑力，以至于可以重新安排这些事件而不会产生什么后果，而事实上它们不能。

此外，每个事件都必须知道谁在设置/修改其输入值，这实际上是全局范围变量的别名，违反了“告诉不问原则”。

2) 单元测试，我可以看到如何测试每个事件，但我还没有看到如何测试整个工作流程。例如。如果在 30 天后没有收到用户的输入，我应该如何模拟发送电子邮件的工作流？但是，我不愿意将单元测试完全排除在外，因为工作流毕竟是一个分支逻辑，因此很复杂，因此错误的可能性太大而无法忽视。

3) 整个工作流基础看起来耦合度很高。它是持久性 + 工作流 + 表达式树构建器(有点)。我希望它能以某种方式更优雅一些(比如响应式框架 Rx)，但我必须谦虚地承认，我不知道有什么更好/更快的方式来处理长时间运行的进程。

总而言之，有限状态机通常很复杂。尤其是对于特征蠕变(是的，认真考虑协变和逆变等)以及长时间运行的进程更是如此。我很乐意将 FSM 用于很少改变的事情，例如。 C# 编译器，但对于那些应该是流动的而不是像您的一般业务需求那样严格的东西，我担心滥用它的诱惑很大，从而使代码无法维护。然而，业务流程中的工作流非常关键，很难放弃这项技术。

我是不是太自卫了？你怎么看？我怎样才能避免陷阱？

提前致谢!

Answer 1

看来您正在查看 WF 3.5，而不是 WF 4。

1) Inside the workflow all variables are either global or activity scoped.

WF 4 引入了创建作用域的容器事件。

2) Unit Testing.

参见 Windows Workflow Foundation on CodePlex ，尤其是 Microsoft.Activities.UnitTesting。本书Pro WF: Windows Workflow in .NET 4.0有单元测试事件的例子。请记住，工作流和事件是可以互换的。参见 WorkflowInvoker.Invoke一种在单元测试中同步执行工作流(或事件)的方法。

3) The whole workflow foundation looks so heavily coupled

WF 4 解耦持久性，其中之一。

是的，工作流程可能会被滥用；见The Danger of Centralized Workflows .我相信它们在涉及人类参与者的长期运行过程中占有一席之地。