试图扩展我上面的评论:我帮助一些同事发展和部署了一个基于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 -专家文档/html/ch01.html
1.2.2。什么时候应该使用规则引擎?
对此的最短回答是“当没有令人满意的传统编程方法来解决问题时”。鉴于这个简短的答案,需要更多解释。没有“传统”方法的原因可能是以下之一:
这个问题对于传统代码来说太麻烦了。
问题可能并不复杂,但您看不到为它构建解决方案的可靠方法。
这个问题超出了任何明显的算法解决方案。
这是一个需要解决的复杂问题,没有明显的传统解决方案,或者基本上没有完全理解问题。
逻辑经常变化
逻辑本身甚至可能很简单,但规则经常变化。在许多组织中,软件版本很少而且相距甚远,可插拔规则可以帮助以合理安全的方式提供所需和预期的“敏捷性”。
领域专家(或业务分析师)随时可用,但不是技术性的。
领域专家通常拥有丰富的业务规则和流程知识。它们通常是非技术性的,但可能非常合乎逻辑。规则可以让他们用自己的方式表达逻辑。当然,他们仍然需要批判性地思考并具备逻辑思维能力。许多非技术职位的人没有接受过形式逻辑方面的培训,所以要小心并与他们一起工作,因为通过将业务知识编入规则中,您经常会暴露当前理解业务规则和流程的方式中的漏洞。
最后一句话就像一张三美元的钞票一样假。
如果您认为项目经理或秘书会在不涉及开发人员的情况下更改规则,因为“它们只是规则,而不是 Java 文件”......继续希望:D
除了编程技能外,规则还需要相当好的分析技能,恕我直言,“Java”更容易。非技术人员(通常指 PM)通常无法掌握修改所需的知识,也无法理解规则。
相反,加粗的点是真正的附加值。
如果您正在开发一个应用程序来处理抵押贷款等问题,并且每个月都会更改数学规则(利息税、系数等),那么使用Drools
它是很好的选择。您无需更改应用程序的逻辑,只需更改公式,奇迹就会发生。
但是如果你使用它是Drools
因为你认为它会阻止你的 webapp 被部署(阅读:降低发布管理的成本),那么你应该三思而后行。
我建议在做出决定之前至少进行几周的侦察;这是一种可能会在你手中自动爆炸的东西:/
从上面链接的相同文档中:
1.2.3。何时不使用规则引擎
定期引用 Drools 邮件列表:
在我看来,在使用规则引擎的兴奋中,人们忘记了规则引擎只是复杂应用程序或解决方案的一部分。规则引擎并非真正旨在处理工作流或流程执行,也不是旨在执行规则的工作流引擎或流程管理工具。为工作使用正确的工具。当然,一把钳子可以在紧要关头用作锤击工具,但这不是它的设计目的。——戴夫·哈姆
由于规则引擎是动态的(在规则可以作为数据存储、管理和更新的意义上是动态的),它们通常被视为部署软件问题的解决方案。(大多数 IT 部门的存在似乎是为了防止软件推出。)如果这是您希望使用规则引擎的原因,请注意,当您能够编写声明性规则时,规则引擎工作得最好。作为替代方案,您可以考虑数据驱动设计(查找表)或脚本处理引擎,其中脚本在数据库中进行管理并且能够即时更新。
最后的想法是,您描述的要求在我看来似乎是静态的,不能发展那么多
1) 用户选择一个对象
2)用户选择多个对象
这几乎不会变得不同,我从未见过应用程序或网站以不同的方式在2
, 3
or10
元素之间处理多选。它是==1
,或者它是>1
。
如果它会发展,那么您也需要更改代码;如果今天您将为 执行一项操作>1
,明天您将为>1 && <=5
和 for >5
...执行两项不同的操作,那么您也必须编写这些新操作。
这不是 Drools 的本意,在我谦虚的观点中。