已关闭。此问题为opinion-based。当前不接受答案。
**想要改进此问题吗？**请更新此问题，以便editing this post可以用事实和引文来回答。
昨天关门了。
社区昨天讨论了是否重新讨论此问题，并将其关闭：
原始关闭原因未解决
Improve this question
我不是口水Maven。不过通过试验，我对它有一些熟悉。我无法理解，为什么我需要它。
我的典型应用程序是商业Web应用程序。是的，它们确实有一些规则。但这些规则是使用数据库表、SQL查询和一个漂亮的UI来实现的，以便业务用户修改规则。规则不是任意的，它们在投入生产之前是经过深思熟虑的。
我的商业用户永远不会使用（Drools）脚本语言来修改任何东西。更不用说修改规则了。他们非常喜欢使用UI屏幕来修改规则。另外，如果我让他们接近它，他们可以在Drools文件中犯无数的语法错误。
又来了
- 在这种情况下，为什么要使用Drools？
- 我遇到过一些Drools狂热分子，他们坚持我应该修改所有的代码来使用Drools。
那么，口水有用吗？我不确定。
3条答案
按热度按时间9rnv2umw1#
各种各样的狂热分子都应该被质疑，不管他们对什么主题赞不绝口。
数据驱动的决策表是实现复杂行为的一个非常好的方法，如果它不能满足您的需求，也许您会考虑其他方法。
除非我有一个令人信服的理由，否则我不想在工作的产品代码中进行技术交换。这比粉丝男孩的游说要多得多。
如果你真的感兴趣，做一个PoC，得到一些真实的数据。如果不感兴趣，学习如何礼貌地微笑和忽略他们。
我以前回答过这个问题：
规则引擎-优点和缺点
最新消息：如果是你的老板，而且你不能解雇他，那就让它基于接口，并在PoC中尝试Drools的实现。如果你正在使用Spring，注入一个，然后再注入另一个，在有意义的生产额定负载下测量性能。获得一些真实的数据--也许你们都会学到一些东西。
uyhoqukh2#
规则引擎的优点是：
*声明式编程：规则使表达困难问题的解决方案和验证解决方案变得容易。与代码不同，规则是用不太复杂的语言编写的;业务分析师可以轻松地阅读和验证一组规则。
*逻辑和数据分离：数据驻留在域对象中，业务逻辑驻留在规则中，根据项目的类型，这种分离是非常有利的。
*速度和可扩展性：Drools所基于的Rete OO算法已经是一个经过验证的算法。在Drools的帮助下，您的应用程序变得非常可伸缩。如果有频繁的更改请求，您可以添加新规则，而不必修改现有规则。
*知识集中化：通过使用规则，您可以创建一个可执行的知识存储库（知识库）。它是业务策略的单一真实点。理想情况下，规则可读性很强，还可以用作文档。工具集成：Eclipse等工具提供了编辑和管理规则以及获得即时反馈、验证和内容帮助的方法，还提供了审计和调试工具。
*解释设施：规则系统能够记录规则引擎做出的决策沿着做出决策的原因，从而有效地提供了“解释工具”。
*可理解的规则：通过创建对象模型和（可选的）领域特定语言来建模你的问题领域，你可以让自己编写出非常接近自然语言的规则，它们有助于领域Maven（可能是非技术Maven）理解的逻辑，因为它们是用他们的语言表达的，所有的程序管道和技术诀窍都隐藏在普通代码中。
6kkfgxo03#