工作流基础设计问题/注意事项？
我正在审查这项技术，但有一些设计问题让我停顿了几次。有人可以帮我纠正一下吗？
1) 在工作流内部，所有变量都是全局变量或活动范围变量。如果您想将它们绑定到活动的输入/输出参数，那么它们需要是全局范围的。我们都处理过管理持久的、全局范围的变量。
我的另一个担心是，这种全局范围的变量存在巨大的诱惑，以至于可以重新安排这些活动，而几乎不会产生任何后果，而事实上这是不可能的。
此外，每个活动都必须知道谁在设置/修改其输入值，这实际上是全局范围变量的别名，违反了“告诉不要问原则”。
2）单元测试，我可以看到如何测试每个活动，但我还没有看到如何测试整个工作流程。例如。当 30 天后没有收到用户的输入时，我该如何模拟发送电子邮件的工作流程？但是，我不愿意完全将单元测试排除在外，因为工作流程毕竟是分支逻辑，因此很复杂，因此出现错误的可能性太大，不容忽视。
3）整个工作流程基础看起来耦合度很高，即。它是持久性+工作流程+表达式树构建器（有点）。我希望它能以某种方式更优雅一些（就像反应式框架 Rx 一样），但我必须谦虚地承认，我不知道有更好/更快的方式来处理长时间运行的流程。
所以总而言之，有限状态机通常很复杂。特别是对于功能蠕变（是的，认真考虑协变和逆变等），以及长时间运行的流程。我很喜欢使用 FSM 来处理很少改变的事情，例如。 C# 编译器，但对于那些应该是流动的而不是像您的平均业务需求那样严格的东西，我担心有很大的诱惑来滥用它，从而使代码难以维护。然而，业务流程中的工作流是如此关键，因此很难放弃这项技术。
我是不是太防守了？你怎么看？我怎样才能避免陷阱？
提前致谢！
I am reviewing this technology but have a few design concerns that made me pause a few times. Can someone help straighten me up?
1) Inside the workflow all variables are either global or activity scoped. If you want to bind them to input/output argument of an activity, then they will need to be globally scoped. And we all have dealt with managing long lasting, globally scoped variables.
My other fear is that there is great temptation with such globally scoped variables that these activity can be re-arranged with little consequence, when in fact they can't be.
Also that each activity must be aware of who is setting/modifying their input values, which is actually an alias to the globally scoped variables, violating the "Tell don't ask principle".
2) Unit Testing, I can see how each activity can be tested, but I am not seeing how the workflow as a whole can be tested yet. Eg. How am I supposed to simulate the workflow sending an email when it does not receive an input from a user after 30 days? However, I'm not comfortable leaving Unit Test out of the picture entirely, since the workflow is after all a branching logic, hence complex, hence the potential for error is too great to ignore.
3) The whole workflow foundation looks so heavily coupled ie. it's persistence + workflow + expression tree builder (kinda). I wished it were a little more elegant somehow (like the reactive framework Rx), but I gotta humbly admit, I don't know a better/faster way of doing things for long running processes.
So in conclusion, finite state machine is usually complex. Especially with feature creeps (yeah seriously think about covariant and contravariant etc.) and more so on long running processes. I'm fine with using FSM for things that rarely change eg. the C# compiler, but for something that is supposed to be fluid rather than rigid like your average business requirement, I fear that there is great temptation to abuse it and thereby making the code unmaintainable. However, workflow in a business process is just so critical, it is hard to pass up on the technology.
Am I just too defensive? What's your take? How can I avoid the pitfalls?
Thanks in advance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您似乎正在查看 WF 3.5，而不是 WF 4。
WF 4 引入了创建范围的容器活动。
请参阅 CodePlex 上的 Windows Workflow Foundation，尤其是 Microsoft.Activities.UnitTesting。 Pro WF: .NET 4.0 中的 Windows 工作流一书提供了以下单元的示例-测试活动。请记住，工作流程和活动是可以互换的。请参阅 WorkflowInvoker.Invoke 了解执行工作流（或活动）的一种方法）在单元测试中同步进行。
3)其一，
。是的，工作流程可能会被滥用；请参阅集中式工作流程的危险。我相信它们在涉及人类参与者的长期运行流程中占有一席之地。
It appears that you're looking at WF 3.5, not WF 4.
WF 4 introduces container activities that create scopes.
See Windows Workflow Foundation on CodePlex, especially Microsoft.Activities.UnitTesting. The book Pro WF: Windows Workflow in .NET 4.0 has examples of unit-testing activities. Remember that workflows and activities are interchangeable. See WorkflowInvoker.Invoke for one way to execute a workflow (or activity) synchronously in a unit test.
WF 4 decoupled persistence, for one.
And yes, workflows can be abused; see The Danger of Centralized Workflows. I believe they have their place for long-running processes that involve human actors.