workflow - WF 的有力案例

Question

我长期以来一直在努力寻找一个令人信服的工作流用例(即:WF)来对抗常规的命令式编程。每次我都会得出这样的结论:我应该把 WF 排除在外，或者推迟到以后再做。但我总有一种挥之不去的感觉，总觉得缺少了一些东西。

有人知道有哪本书真正为工作流方式提供了强有力的论证吗？这本书必须 (i) 很好地教授 WF，并且 (ii) 使用适当的用例来展示 WF 使实现比我们只进行常规的直接编码更容易。

我会很感激。

Answer 1

从非专家的角度来看，对我来说，WF 有两点值得支持——一是工作流平台所独有的，二是可能更方便。

便利的功能是能够创建新的事件组合方式。命令式编程仅提供有限的组合原语:基本上是排序、if-else 和循环。 WF允许您构建自己的组合运算符，例如交错执行、并行执行、先过后后等。当然，它还内置了复杂的状态机组合机制。

我说这是一个便利的功能，因为您可以使用 C# 等命令式语言构建所有这些运算符:事实上，这就是构建 WF 运算符的方式。但是 WF 使使用和读取自定义组合变得容易，而在 C# 中，您很快就会陷入大量 lambda 表达式中。因此，如果您有复杂的编排要求——也就是说，如果您的事件组合在一起的方式比序列、if-else 和循环更复杂——那么 WF 可能会让您的程序更容易表达和理解。

独特的功能是耐用性。这是舒克拉和施密特这本书的出发点，也是它不断回归的地方。用 C# 或 VB 编写的命令式程序可以运行数小时、数天、数周(如果幸运的话)，甚至可能数月……但最终 IIS 将循环应用程序池，或者管理员将要安装最新的安全更新，或者有人会被电源线绊倒。那么你的程序如何记住，“好吧，我已经收到了 Unimaginative Company Names R Us 的采购订单，我正在等待 Bank of Breadheads Inc. 的信贷批准，当我收到批准后，我可以发送确认信息电子邮件”？

在传统的命令式程序中，当进程终止时，执行状态也随之终止。您可以启动一个新进程，但它将在程序的开头启动。当然，您可以创建一个数据库并使用它来存储“已获得采购订单”和“已获得信用批准”等标志。但现在您必须编写特定于应用程序的代码来保存和查询状态，并根据该状态跳回到程序中的正确点。您必须为每个长时间运行的应用程序设计一个新的数据库和新的保存/恢复/跳转逻辑。

持久工作流程就是为了解决这个问题。如果您将程序编写为事件工作流，那么 WF 将负责保存其状态，包括其在执行流中的位置。运行该程序的机器可能会着火并烧毁您的数据中心，但是当银行的响应到来时，WF将唤醒您在另一个数据中心的程序，并且它将开始在正确的位置以正确的方式运行数据。

对我来说，这就是 WF 的“强有力的理由”。在许多情况下，您不需要它:应用程序的生命周期很短，因此故障并不是一个重要的问题，并且从头开始重新启动是一种可行的恢复策略。但对于长期存在的应用程序，例如您可能正在编排可能需要数小时才能响应的外部系统，或者涉及可能需要数天才能响应的人员的业务流程，持久性可能是 WF 的 killer 级功能。

免责声明:我不是 WF 程序员，也从未构建过实际的 WF 系统。我是从 BizTalk 背景以及我所读到的有关 WF 的内容中得出这个结论的，所以这个评估有点理论化。希望它对大家都有帮助!