我们拥有庞大的网络应用程序，并且正在为其添加新功能。 由于它是 Web 应用程序，它使用 Struts2、Spring 框架。
我google了很多，没找到Jboss Drools在Web Application中的使用教程。
谁能告诉我基于 Web 应用程序/项目的 Drools 教程。
是否可以配置 Drools，如果用户在 JSP 中选择几个选项，基于所选选项，我可以启动 Drools 引擎吗？通过触发，我应该能够动态更改视图。
假设购物车 [查看页面] 中有三个产品。如果用户选择 A 产品，我应该向他展示更多选项，如果用户同时选择 A 和 B，则禁用选择第 3 个产品等... [从 Drools 进行视图控制]
【问题讨论】：
标签： java spring web-applications struts2 drools
试图扩展我上面的评论：我帮助一些同事发展和部署了一个基于 Struts2 / Spring 和大量 .drl 文件（133 个文件，从 500 到 3000 行）的巨大、丑陋的 Web 应用程序每个）。
我可以肯定地说我现在知道如何不使用Jboss Drools：表示逻辑、工作流管理等等。
Jboss Drools 不是垃圾。 Jboss Drools 是一个很棒的工具......如果它被用于它的设计：帮助您处理应用程序的逻辑规则。
问题在于，人们通常会根据这些技术看起来很酷或有一个响亮的名字来选择需要将哪些技术放入他们的堆栈中，而不是真正需要使用它们，也不是在一些好的（或至少，执行）侦察。
Drools 它学起来不（那么）快，（肯定）集成不那么快，维护起来也不（那么）容易，如果它被用于错误的目的，它会吞噬数周/数月的工作结果可能与预期不同（可能低于预期）。
来自官方Drools Expert 文档（还有其他Drools，查看它们），您可以在其中找到示例以及您在此问题中提出的所有问题：http://docs.jboss.org/drools/release/5.2.0.Final/drools-expert-docs/html/ch01.html
1.2.2。什么时候应该使用规则引擎？
对此的最短回答是“当没有令人满意的 解决问题的传统编程方法。”。鉴于 简短的回答，需要更多的解释。之所以有 不是“传统”方法可能是以下之一：
这个问题对于传统代码来说太麻烦了。
问题可能并不复杂，但您看不到为它构建解决方案的可靠方法。
这个问题超出了任何明显的算法解决方案。
这是一个需要解决的复杂问题，没有明显的传统解决方案，或者基本上没有完全理解问题。
逻辑经常变化
逻辑本身甚至可能很简单，但规则经常变化。在许多组织中，软件版本很少而且相差甚远 和可插入的规则可以帮助提供所需的“敏捷性”，并且 以合理安全的方式预期。
领域专家（或业务分析师）很容易获得，但不是技术人员。
领域专家通常拥有丰富的业务规则和流程知识。它们通常是非技术性的，但可能非常 合乎逻辑。规则可以让他们用自己的方式表达逻辑。 当然，他们仍然必须批判性地思考并有能力 逻辑思维。许多非技术职位的人没有 形式逻辑的培训，所以要小心并与他们一起工作，如 将业务知识编入规则中，通常会暴露出漏洞 当前理解业务规则和流程的方式。
最后一句话就像一张三美元的钞票一样假。
如果您认为项目经理或秘书会在不涉及开发人员的情况下更改规则，因为“它们只是规则，而不是 Java 文件”...继续希望 :D
除了编程技能外，规则还需要非常好的分析技能，恕我直言，“Java”更容易。 非技术人员（通常指 PM）一般无法掌握修改所需的知识，也无法理解规则。
相反，粗体点是添加的真实值。
如果您正在开发一个处理抵押贷款等问题的应用程序，其数学规则每个月都会发生变化（利息税、系数等），那么使用Drools 是很好的选择。您无需更改应用程序的逻辑，只需更改公式，奇迹就会发生。
但是，如果您使用Drools 是因为您认为它会阻止您的 webapp 被部署（阅读：降低发布管理的成本），那么您应该三思而后行。
我建议在做出决定之前至少进行几周的考察；这是那种可能会在你手中爆炸的东西自动：/
来自上面链接的相同文档：
1.2.3。何时不使用规则引擎
引用 Drools 邮件列表的常规：
在我看来，在使用规则引擎的兴奋中，人们忘记了规则引擎只是复杂的一部分 应用程序或解决方案。规则引擎并不是真的打算 处理工作流或流程执行，也不是工作流引擎或 流程管理工具旨在做规则。使用正确的工具 工作。当然，一把钳子可以用作锤击工具 捏，但这不是它的设计目的。 ——戴夫·哈姆
由于规则引擎是动态的（在规则可以作为数据存储、管理和更新的意义上是动态的），它们通常是动态的 被视为部署软件问题的解决方案。 （最多 IT部门的存在似乎是为了防止软件 正在推出。）如果这是您希望使用规则的原因 引擎，请注意规则引擎在您能够 编写声明性规则。 作为替代方案，您可以考虑 数据驱动设计（查找表）或脚本处理引擎 脚本在数据库中管理并且可以更新 在飞行中。
作为最后的想法，你描述的需求在我看来是相当静态的，不能那么发展太多
1) 用户选择一个对象
2) 用户选择多个对象
这几乎不会有什么不同，我从未见过应用程序或网站在 2、3 或 10 元素之间以不同的方式处理多选。是==1，或者是>1。
如果它会发展，那么您也需要更改代码；
如果今天您将为>1 执行一项操作，明天您将为>1 && <=5 和>5 执行两项不同的操作...那么您也必须编写这些新操作。
这不是 Drools 的本意，在我谦虚的观点中。
【讨论】：