建模作业执行流程的设计模式

Question

在我的应用程序中，我有一组要执行的作业。每个作业都会经历“未开始”、“已开始”、“已完成”、“失败”等状态。每个作业都有一组前置条件和后置条件。在满足前置条件之前，作业无法启动，如果不满足后置条件，则应将其标记为失败。

例如，假设作业将文本文件导入数据库。前置条件是检查源文件是否存在，后置条件是检查数据库中是否存在数据。

除了这些前置条件和后置条件之外，有时一项工作还依赖于其他工作才能完成。创建作业表和作业依赖表很容易，但实际上是否有可能使这些验证前和验证后检查在数据库中可配置（这样如果这些条件发生变化或不需要更改代码）添加了新条件）？即使有可能，这样做是个好主意吗？

需要使该模型具有通用性，以便其他应用程序也可以使用它，即使要执行的验证检查对于其他应用程序完全不同。

Answer 1

我认为您冒着尝试过多使用桌面驱动器的风险。通过尝试表驱动所有验证前和验证后条件，您将危险地接近尝试在数据中编写代码。

我已经构建了一些非常复杂的作业调度应用程序。一个特别有趣的可能是每天的 ETL 过程，它基于平面文件提要加载数十个 SQL 表。

现有系统使用线性过程，程序员必须手动计算表间依赖关系并按给定顺序运行表加载。这样做的问题是，如果任何进程失败，其余的工作就必须坐下来等待问题解决。

我构建了一个新系统，该系统具有表驱动的元数据，指出了直接的表间依赖关系。换句话说，表 A 对表 B 和 C 具有 FK。不是手动跟踪 所有 的相互依赖关系，而是只跟踪直接的相互依赖关系。然后调度程序只需要查看哪些加载已经完成，哪些加载没有完成。任何没有不完整依赖关系的挂起加载都可以开始。

我认为您应该类似地构建您的系统。使用关注点分离。不要表驱动依赖项是什么，而应该只表驱动存在哪些依赖项。您可以在调度表中跟踪这些依赖项中的哪些已通过，哪些已失败。数据库不需要知道如何进行这些测试。让代码担心依赖到底是什么以及如何测试它们是通过还是失败。这就是您的作业调度程序需要知道的全部内容。避免创建源代码位于数据库中的脚本语言的诱惑。

Answer 2

考虑将您的应用程序与规则引擎（也称为业务规则）集成。这个想法是逻辑在代码之外定义并存储在表或文件中。规则引擎读取规则并进行解释。

这些软件很快就会变得复杂。大多数情况下，它们是商业包，但存在一些免费和开源框架。我没有使用任何免费软件包。一般来说，我建议查看现有代码，而不是从头开始构建规则引擎。

Martin Fowler 的精彩介绍： http://martinfowler.com/bliki/RulesEngine.html

一篇内容更丰富的文章： http://www.infoq.com/articles/Rule-Engines

要查找实际代码，请在“规则引擎”或“工作流引擎”上搜索 Google，并添加您的编程语言的名称（“Java”、“C#”或其他名称）。