为什么我们不能用Java文件而不是.drl文件编写业务规则？

Question

我刚刚介绍了Business Rules，.drl文件，Rule Engines和Drools.While探索我意识到所有这些条件和事实检查都可以在Java程序中完成，那么为什么我们需要编写.drl文件和有一个规则引擎。

我在互联网上找到的示例并没有区分为什么我们应该为一个特殊的业务逻辑编写.drl文件而不是将逻辑放在Java类中。 使用示例的解释将是一个很大的帮助。

Answer 1

使用规则引擎的常见优点包括：

• 声明性业务规则：使用业务分析师（而非开发人员）可用于定义业务规则的DSL，可以采用“让业务分析人员管理业务规则时让开发人员进行编码”等方法。
• 外化规则：这可能（取决于所选的规则引擎）允许您更改这些规则，而无需重建和重新部署整个应用程序。
• 非功能：专用规则引擎可以比代码中隐藏的一系列if / then / else子句更好地执行（例如通过并发执行），类似地，专用规则引擎可以提供更好的诊断和规则决策的可见性而不是自己动手的解决方案。当然，这些并不一定是正确的，但是如果说自己的解决方案在这方面要匹配或超过一个使用良好的规则引擎，那么这样做需要一些非常简单的开发。

（还有其他人，但为了这个答案的目的，我认为以上就足够了。）

当然，取决于每种情况的具体情况，这些优点或多或少具有重量。因此，举例来说，如果拟议的业务规则非常简单，数量很少，不太可能改变，如果对执行时间有宽松的期望，则上述许多优点都不适用。

然而，大量的实施开始时小而简单，预计未来几乎没有变化，只有所有这些期望受到现实的挑战：）

在某种程度上你也可以使用Drools 和＆＃34;把...逻辑放在Java Class＆＃34;使用Drool的Java方言。

如果您被鼓励根据您的意愿使用Drools，那么或许妥协的解决方案是围绕您的规则实现包装一个接口，并从该接口的简单实现开始，以便以后可以实现基于Drools的实现/当一个令人信服的案件可以为它做出时。

Answer 2

这个想法是：

1. 不要将业务规则与应用程序逻辑混淆
2. 要将.drl文件与应用程序分开，以便可以单独更新。
3. 理想情况下，虽然我怀疑这在实践中是否已经实现，但业务主题专家可以自己编写业务规则。