Java规则引擎的优缺点[关闭]

Posted 2023-02-19

【中文标题】Java规则引擎的优缺点[关闭]

【英文标题】：Pros and cons of Java rules engines [closed]

【发布时间】：2011-01-11 03:52:14

【问题描述】：

采用Java 规则引擎JESS 和Drools 的优缺点是什么？还有其他玩家吗？

我知道 Drools 是开源的，而 JESS 不是，但它们在易用性、性能、与您的代码的集成程度等其他方面如何比较？

【参考方案1】：

采用 Java 规则引擎 JESS 和 Drools 的优缺点是什么？

如果您需要将业务规则与应用程序逻辑分开，请使用规则引擎。 Does Your Project Need a Rule Engine 的文章有一个很好的例子：

例如，典型的店面 系统可能涉及计算代码 打折：

if (product.quantity > 100 && product.quantity < 500) 
  product.discount = 2;
 else if (product.quantity >= 500 && product.quantity < 2000) 
  product.discount = 5;
 else if (product.quantity >= 2000) 
  product.discount = 10;

规则引擎将上述内容替换为 代码如下：

ruleEngine.applyRules(product);

由您决定将规则管理控制台交给非技术人员是否是一件好事 :)

Should I use a Rules Engine?、Why use a Rule Engine?、Some Guidelines For Deciding Whether To Use A Rules Engine 和Google 中的更多详细信息。

还有其他玩家吗？

其他参与者包括 JRules、Corticon（JRules 是最著名的 IMO - 这并不意味着最好）。

它们在易用性、性能、与您的代码的集成程度等其他方面如何比较？

不能准确地告诉你，我对 Drools 的体验只有一点点（积极的）经验。但是您会从博客文章中获得一些反馈，例如 JBoss Drools vs ILog JRules - an anecdotal story（请务必阅读）或 Working with Drools from a JRules perspective。我相信你可以在 Google 上找到更多（但我会试试 Drools）。

【讨论】：

您的答案看起来不错。你能告诉我在哪里使用口水以及在哪里使用 Jess 吗？基本上，我期待答案更相关的差异。黑白流口水和杰西。

哇，@Pascal，该产品数量/折扣示例是真正的 WTF。假设数量是 5,000。第一个 IF 评估为真，永远不会评估 ELSE IF。将这种业务逻辑放在规则引擎中并没有任何帮助，尽管它可能会使查找错误变得更加困难。

在他的辩护中，这个例子来自第一篇文章。不太确定那个人看起来有多可信......:)

只是将规则控制交给非技术人员的危险的一个很好的例子。

为什么要使用规则引擎？是列出的链接中最好的

【参考方案2】：

我们现在正在评估与我们的应用服务器一起使用的规则。我们遇到了OpenRules，它很容易与 Java 集成，而且就我们的测试表明，它足够快。 OpenRules 的主要优势在于修改和处理规则的方式。这一切都发生在 Excel 表格中，这对于非程序员来说是最简单的方法。参与其中的每个人，即使是非技术人员，都完全理解一切:-)

我们还集成了 drools，但规则更难理解，因为它是一种更程序化的方法。这就是为什么我们 - 很可能 - 会坚持使用 OpenRules。

【讨论】：

Drools 还支持在 Excel 中和通过 Web 界面编辑的规则。

【参考方案3】：

我们有类似的问题，我们终于拿起了 Drools，如果你有以下情况，应该使用 drools：

您认为由于多种情况而导致多个 if 条件混乱的业务逻辑 您将越来越需要增加复杂性 业务逻辑变化会很频繁（一年1-2次也会很频繁） 您的服务器有足够的内存，因为它是一个需要大量内存的工具，它以内存为代价提供性能

更多详情请关注URL

【参考方案4】：

只是补充说，许多人正在寻找更类似于管理是否满足某些条件来启用或禁用应用程序中的某些功能的东西。

我厌倦了在任何地方一遍又一遍地重新实现相同的模式，所以我决定为其创建一个名为 Roolie http://sourceforge.net/projects/roolie/ 的 OSS 项目

我只是对其进行了 maven 化，并且由于自 2010 年发布以来没有报告任何错误，因此我将其升级到 v 1.0，除了在 Maven 中心（我在做的过程）。

基本上，JSR-94 对大多数事情来说都是多余的，并且与当前的产品一起存在巨大的学习曲线和开销。如果那是你想要的，那很好。但是，如果您只想将用 Java 编写的简单规则与 XML 链接在一起以维护您的状态测试，那么 Roolie 是一种非常快速的方法。没有依赖关系，没有学习曲线。

【讨论】：

Roolie 声明它在 SourceForge 上获得 MIT 许可，但代码报告 LGPLv3。这实质上意味着在任何商业产品中使用它都是可疑的（在一些开源产品中也是如此）。见nmav.gnutls.org/2013/03/the-perils-of-lgplv3.html。

【参考方案5】：

当我们需要一个规则引擎时，我们决定推出自己的规则引擎，因为可用的规则引擎对于我们的简单任务来说太复杂了。如果您甚至对解析用户可能输入的表达式有一定的经验，这并不是很难做到的。在我们的例子中，大部分规范由 XSD 处理，只有少数字段被进一步解析。

【讨论】：

规则引擎使用成熟的算法（例如前向链接和 Rete 算法）来扩展处理非平凡问题。如果您只是简单地评估表达式，那么现有的库（例如 MVEL）可能会很有用。