Java 规则引擎的优缺点

Pros and cons of Java rules engines

提问by brabster

What are the pros and cons to adopting the Java rules engines JESSand Drools? Are there any other players?

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

I understand that Drools is Open Source and JESS is not, but how do they compare in other areas like ease of use, performance, level of integration with your code?

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

回答by Dominik Sandjaja

We are evaluating rules now for use with our application server. We have come across OpenRules, which is easy to integrate with Java and, as far as our testing has shown, fast enough. The main advantage of OpenRules above the others is the way the rules are modified and handled. It all happens in Excel tables, which is the easiest way for non-programmers. Everybody involved, even the non-technical people, understood everything perfectly :-)

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

We also have drools integrated, but the rules are way more complicated to understand as it is a more programmatic approach. That's why we - most likely - will stick to OpenRules.

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

回答by Pascal Thivent

What are the pros and cons to adopting the Java rules engines JESS and Drools?

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

Use a rule engine if you need to separate the business rules from the application logic. The Does Your Project Need a Rule Enginearticle has a good example:

如果您需要将业务规则与应用程序逻辑分开，请使用规则引擎。在做您的项目需要一个规则引擎文章有一个很好的例子：

For example, a typical storefront system might involve code to calculate a discount:

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;
}

A rule engine replaces the above with code that looks like this:

ruleEngine.applyRules(product);

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

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);

Up to you to decide whether putting a rule admin console in the hands of non-technical people is a good thing or not :)

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

More details in Should I use a Rules Engine?, Why use a Rule Engine?, Some Guidelines For Deciding Whether To Use A Rules Engineand on Google.

在更多的细节，我应该使用规则引擎？，为什么要使用规则引擎？，决定是否使用规则引擎和在谷歌上的一些指南。

Are there any other players?

还有其他玩家吗？

Other players include JRules, Corticon (JRules is the most famous IMO - which doesn't mean the best).

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

how do they compare in other areas like ease of use, performance, level of integration with your code?

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

Can't tell you precisely, I only have a little (positive) experience with Drools. But you'll get some feedback from blog posts like JBoss Drools vs ILog JRules - an anecdotal story(be sure to read it) or Working with Drools from a JRules perspective. I'm sure you can find more of them on Google (but I would give Drools a try).

不能准确地告诉你，我对 Drools 只有一点（积极的）经验。但是您会从JBoss Drools 与 ILog JRules 之类的博客文章中获得一些反馈——一个轶事故事（一定要阅读它）或从 JRules 的角度使用 Drools。我相信您可以在 Google 上找到更多（但我会尝试使用 Drools）。

回答by Confusion

When we needed a rules engine, we decided to roll our own, because the available ones were far too complicated for our simple tasks. If you are even remotely experienced with parsing expressions users may put in, this is not very hard to do. In our case, most of the spec is handled by an XSD and only a few of the fields are parsed further.

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

回答by R K

Just adding that many people are looking for something more akin to managing whether certain conditions are met to enable or disable certain features in an application.

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

I grew tired of re-implementing the same pattern over and over everywhere I went, so I decided to make an OSS project for it called Roolie http://sourceforge.net/projects/roolie/

我厌倦了在我所到之处一遍又一遍地重新实现相同的模式，所以我决定为它制作一个名为 Roolie 的 OSS 项目http://sourceforge.net/projects/roolie/

I just maven-ized it and since there have been no bugs reported since 2010 when it was released, I upgraded it to v 1.0 with no changes other than those required to host it at Maven Central (which i'm in the process of doing).

我只是对它进行了 Maven 化，因为自 2010 年发布以来没有报告任何错误，所以我将它升级到 v 1.0，除了在 Maven Central 托管它所需的那些之外没有任何更改（我正在做的过程中） ）。

Basically JSR-94 is overkill for most things, and there is a huge learning curve and overhead that go along with the current offerings. That's fine if that's what you want. But if you just want to chain simple rules written in Java together with XML to maintain your state tests, Roolie is a very fast way to do it. No dependencies and no learning curve.

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

回答by Sachin Thapa

We had similar question with us, we finally picked up Drools, one should use drools if you have following:

我们遇到了类似的问题，我们终于选择了 Drools，如果您有以下情况，应该使用 Drools：

• Business logic which you think is getting cluttered with multiple if conditions because of variety of scenarios
• You will have growing demand of increase in the complexity
• The business logic changes would be frequent (1 - 2 times a year would also be frequent)
• Your server's have enough of memory as it is a memory hungry tool, it provides performance at cost of memory

• 由于各种场景，您认为业务逻辑因多个 if 条件而变得混乱
• 您对增加复杂性的需求会越来越大
• 业务逻辑更改会很频繁（一年 1 - 2 次也会很频繁）
• 你的服务器有足够的内存，因为它是一个内存饥渴的工具，它以内存为代价提供性能

Have more details at following URL

在以下网址有更多详细信息