规则引擎 drools_Drools：何时不使用规则引擎

规则引擎 drools

There are a lot of advantages of Rule Engine but that doesn't mean it can be a solution to all the application. It's not a Panacea for business layer so should be used wisely.

规则引擎有很多优点，但这并不意味着它可以成为所有应用程序的解决方案。 它不是用于业务层的灵丹妙药 ，因此应明智地使用。

Below are the points to ponder:

以下是需要考虑的要点：

• If your project is small, possibly with less than 20 rules then a rule engine would probably be an overkill. However, think twice before making a decision, because many systems start small, but as more requirements are implemented, it suddenly becomes unmanageable.

  如果您的项目很小 (可能少于20条规则)，那么规则引擎可能会显得过大。 但是，在做出决定之前，请三思而后行，因为许多系统起步很小，但是随着更多需求的实现，它突然变得难以管理。

• If your business logic is well-defined or static and doesn't change often; you don't need to change rules at runtime.

  如果您的业务逻辑是定义明确或静态的 ，并且不会经常更改； 您无需在运行时更改规则。

• If your rules are simple, self-contained, usually spanning only a single object (for example, a check that a user's age is less than 21). You don't need a rule engine if in pseudocode, you don't have more than two nested if-then statements. Again, consider this carefully because every system grows in complexity overtime.

  如果您的规则很简单 ， 自成体系 ，通常仅跨越一个对象(例如，检查用户的年龄小于21岁)。 如果使用伪代码，则不需要规则引擎；如果嵌套的if-then语句不超过两个，则不需要规则引擎 。 同样，请仔细考虑这一点，因为每个系统的复杂性都会随着时间的推移而增长。

• If the performance is your primary concern. Are you implementing some algorithm where you want to have precise control over its execution? Do you have a memory-constrained environment?

  如果性能是您的首要考虑。 您是否要实现某种算法 ，以对其执行进行精确控制？ 您是否有内存受限的环境？

• If your project is a one-shot effort and it will never be used again or maintained over time.

  如果您的项目只是一次尝试 ，并且永远不会再使用或随着时间的流逝而维护。

• Drools has a learning curve. So the developers have to be aware of the syntax and the execution of rules.

  流口水有学习曲线。 因此，开发人员必须意识到语法和规则的执行。

• To elaborate more on the point, say a Loan Granting Application where the rules are limited and they don't change over time or neither new parameters or fields get added in such kind of applications. What can change is the interest rate which can be read from a static final field.

  要详细说明这一点，请说一个“贷款授予应用程序”，其中的规则受到限制，并且规则不会随时间变化，或者此类应用程序中都不会添加新的参数或字段。 可以改变的是可以从静态最终字段中读取的利率。

  Second example, say a Library Managing Application, while designing the application there are fixed set of rules and once implemented they don't change that frequently or either change at all. Hence in such kind of system its advisable not to use Drools as it wont be of that benefit with respect to performance and the control.

  第二个例子，例如一个图书馆管理应用程序，在设计应用程序时有一组固定的规则，一旦实施，它们就不会经常更改或根本不会更改。 因此，在这种系统中，建议不要使用Drools因为就性能和控制而言，它不会带来任何好处。

  Whereas if you are about to use a Trading Application where you have new regulators on boarded every 3 months and new laws/rules regulating your application and daily new rules being told to implement and where changes are very frequent, its advisable to use Drools.

  鉴于如果您要使用交易应用程序，并且每三个月要有新的监管机构上岗，并且有新的法律/规则来监管您的应用程序，并且每天都会被告知要执行的新规则，并且更改非常频繁，那么建议您使用Drools 。

翻译自: https://www.studytonight.com/drools/not-use-rule-engine

规则引擎 drools