什么时候使用工作流引擎？

Question

作为程序员，我曾经在一些工作流引擎上工作过，但从来不清楚为什么我们首先选择工作流引擎。作为程序员，我知道在编写代码时至少有100种方法可以完成任何事情，但是只有很少的方法是最好的！

我仍然不明白哪些用例最好由工作流引擎(或者更确切地说是它们的概念)解决，而不是设计一个良好的启用DI的应用程序。我正在寻找任何与领域无关的用例的一般特性，其中工作流引擎是最好的选择之一。

因此，我的问题是:一个需求的一般特征是什么，它可以作为选择一个好的工作流引擎并围绕它进行编码的信号？

Answer 1

当您需要从一开始到完成时，工作流引擎是非常有用的，但是有许多不同的路径/逻辑/规则可以实现。

例如，假设我编写了一个发布内容的程序。因此，在我的例子中，出版经历了一个审查过程，合法的，然后最后的批准。我编写了实现我的过程逻辑和步骤的程序。现在这件事对我和我的公司都很有好处。所以，我决定其他人应该使用我的程序。

不幸的是，并不是每个人都使用相同的流程发布内容，因此，我们将不为每个不同的案例编写单独的流程，而是实现一个工作流流程，以便该程序能够灵活地容纳每个人。无论这两点之间有多少步骤、规则或逻辑，结果都是一样的。

因此，如果您的流程自始至终都是可变的，请使用工作流。如果每个人都可以使用相同的流程，那么您就不需要工作流。

Answer 2

我知道您要求用例，但是列出优点要比想象所有可能的用例容易得多。当然，优势取决于您所比较的引擎和语言，但总的来说：

1. 将规则保留为数据而不是代码意味着您不必重新编译，因此您可以快速测试更改，在运行时进行更改等等。不过，如果您一开始就不需要重新编译，那么没有多大优势。
2. 用户可以更合理地编辑规则。当程序员为他们编写代码时，他们可能会以不可行的方式对它们进行交互修改。
3. 将规则保持为数据允许编写工具来可视化和更改数据。
4. 将规则保持为数据允许元编程更容易--您可以编写代码来分析数据，并以某种复杂的方式插入更多内容，这对代码来说是非常困难的。

所有这些事情都可以直接用代码来完成(例如-编写一个C#解析器来查找特定类型的所有规则并为更多的规则生成代码，以允许程序集卸载的方式动态地将其插入到程序集中，为用户编写工具以便能够使用可视化工具和编辑器很好地做到这一点)，但根据您的语言可能要困难得多(使用Lisp的程序员可能将项目1-4称为“编程”)。

Answer 3

IMHO --您应该使用这类东西的唯一情况--是当它可以由价值较低的用户配置时。如果你可以通过给他们一个工具来解决你的问题，然后回到其他更重要的事情上，然后使用一个。

如果您仍然需要为它们设置它，那么我可以想象您可以想出10种不同的方法，使用您熟悉的工具获得相同的结果，而且支持和自定义要容易得多。