为什么规则引擎而不是易于理解的一行属性？

Question

我是一个规则引擎的新手，所以如果这个问题是非常基本的，请容忍我。规则引擎的所有教程都说，您可以将业务逻辑移出代码之外，并让巴斯/最终用户更新业务逻辑，而不是将其放在Java代码中。

我有以下问题

1. 但是为什么我们不能编写代码从属性文件中读取值并做同样的事情呢？
2. 此外，与.properties文件相比，规则文件似乎具有一种语法，而不是简单的一行。
3. 在规则引擎中放置这些规则是否可以使代码/应用程序工作，而不需要重新启动应用服务器？ 3a。如果不这样做，我们又如何做到呢？

Answer 1

在过去的几天里，我一直在阅读(我认为是IMHO)，允许使用简单的电子表格更新业务规则的能力，使规则引擎比属性文件更具优势。我可以使用多个属性和修改规则的指令作为每个属性下的注释，使属性文件尽可能高度可配置。

但是，在业务用户能够直接配置应用程序以基于电子表格中的“决策表”应用值的情况下，该解决方案将更加可取。

如果任何其他(新兴的)开发人员正在寻找关于规则引擎的需要的理由是用这个答案，请留下一个拇指向上！

Answer 2

1. 如果逻辑有变化，您将更改属性文件并再次部署整个项目。然而，如果使用BRMS对其进行维护，则只需在BRMS上单独进行更改和测试，而无需再次部署整个项目。一旦测试完成，并且您最终想要部署新规则，那么，也不需要在生产中部署整个项目。如果您已经使用KIE Server将规则公开为API，那么只重新部署KIE服务器就可以了。
2. 可以以这样的方式编写决策表，即所有的逻辑都包含在最上面的行中。然后，开发人员可以锁定并隐藏这些顶级行，然后将其交给BA。现在BA没有看到任何逻辑，但知道如何维护该文件。另外，并不是所有的逻辑都应该写成决策表。
3. 正如我前面提到的，可以将每个规则部署为单独的rest，因此可以独立于rest部署。

最后，我要说，我们使用Redhat BRMS的主要原因是，正如他们在文档中提到的那样：

1. 敏捷性:不需要让开发人员参与更改请求。BA本身就能改变逻辑。
2. 可见性:你所看到的(在excel中)是你得到的。
3. 一致性:每次评估规则的方式都是相同的。

Answer 3

规则引擎并不总是解决问题的方法。但是，从理论上讲，它们提供了引擎可以对简单规则表达式执行复杂处理并返回结果的优点。其他优点是规则的可见性和代码的减少。

回答你的问题。

1. 你可以的。在简单的情况下，使用属性文件是有意义的。
2. 规则需要足够复杂，以涵盖它们验证的业务问题。一个好的规则引擎使用的语法是可读的，即使它很复杂。
3. 理论上，规则服务器可以独立于应用服务器运行。在大公司，这是正常的。规则服务器可以在不重新启动的情况下允许更新，也可以在不影响应用服务器的情况下重新启动它(如果有多个实例，可以重新启动)。