我有一个相当不错的使用规则引擎的优点列表,以及使用它们的一些原因,我需要的是你不应该使用规则引擎的原因列表
我到目前为止最好的是:
规则引擎并非真正用于处理工作流或流程执行,也不是用于执行规则的工作流引擎或流程管理工具.
你不应该使用它们的任何其他重要原因？
我将从个人经验中给出两个例子,其中使用规则引擎是一个坏主意,也许这会有所帮助: -
在过去的项目中,我注意到规则文件(项目使用Drools)包含很多java代码,包括循环,函数等.它们本质上是伪装成规则文件的java文件.当我向建筑师询问他的设计理由时,我被告知"规则从未打算由商业用户维护".
课程:出于某种原因,它们被称为"业务规则",当您无法设计可以由业务用户轻松维护/理解的系统时,请不要使用规则.
另一个案例; 该项目使用了规则,因为需求定义/理解不当并经常更改.开发团队的解决方案是广泛使用规则以避免频繁的代码部署.
经验教训:在初始版本更改期间,需求往往会发生很大变化,并且不保证使用规则.当您的业务经常更改时(而非要求),请使用规则.例如: - 随着税法的变化,您的税收将逐年变化,并且规则的使用是一个很好的主意.随着用户确定新要求,Web应用程序1.0版将经常更改,但随着时间的推移会稳定下来.不要使用规则作为代码部署的替代方法.
当我看到人们使用非常大的规则集时(例如,在单个规则集中的数千个规则的顺序),我变得非常紧张.当规则引擎是位于企业中心的单身人员时,通常会发生这种情况,希望保留规则DRY可以让许多需要它们的应用程序访问它们.我无视任何人告诉我,Rete规则引擎有很多规则是很容易理解的.我不知道有任何工具可以检查以确保不存在冲突.
我认为分区规则设置为保持较小是一个更好的选择.方面可以是在许多对象之间共享公共规则集的方法.
我希望尽可能采用更简单,更加数据驱动的方法.
我是Business Rules Engines的忠实粉丝,因为它可以帮助您作为程序员让您的生活更轻松.我在处理数据仓库项目时遇到的第一个经验之一就是找到包含复杂CASE结构的存储过程,这些结构遍及整个页面.这是调试的噩梦,因为很难理解在这种长CASE结构中应用的逻辑,并确定代码的第1页和第5页的另一条规则之间是否存在重叠.总的来说,我们有代码中嵌入了300多个这样的规则.
当我们收到一个新的开发要求时,对于一个名为Accounting Destination的东西,涉及处理超过3000条规则,我知道必须改变一些东西.那时我一直在研究一个原型,后来成为现在是自定义业务规则引擎的父级,能够处理所有SQL标准运算符.最初我们一直使用Excel作为创作工具,后来我们创建了一个ASP.net应用程序,它允许业务用户定义自己的业务规则,而无需编写代码.现在系统工作正常,错误很少,并且包含超过7000条规则来计算此会计目的地.我不认为这种情况只能通过硬编码实现.用户非常高兴他们可以定义自己的规则而不会成为他们的瓶颈.
但是,这种方法还是有限的:
您需要拥有对公司业务有深刻理解的有能力的业务用户.
在搜索整个系统(在我们的例子中是数据仓库)中存在很大的工作量,以便确定所有硬编码条件,这些条件有意义地转换为由业务规则引擎处理的规则.我们还必须小心谨慎,这些初始模板是业务用户完全可以理解的.
您需要有一个用于规则创作的应用程序,其中实现了用于检测重叠业务规则的算法.否则你最终会陷入一团糟,没有人能理解他们得到的结果.如果您在通用组件(如自定义业务规则引擎)中存在错误,则可能非常难以进行调试并涉及大量测试,以确保之前可用的工作现在也能正常工作.
关于这个主题的更多细节可以在我写的帖子中找到:http://dwhbp.com/post/2011/10/30/Implementing-a-Business-Rule-Engine.aspx
总体而言,使用业务规则引擎的最大优势是,它允许用户收回对业务规则定义和创作的控制权,而无需在每次需要修改某些内容时都去IT部门.它还减少了IT开发团队的工作量,现在可以专注于构建具有更多附加值的东西.
干杯,
尼古拉·
我注意到的一把"双刃剑"是:
将逻辑放在非技术人员手中
我已经看到这项工作很棒,当你在非技术方面有一两个多学科天才时,但我也看到缺乏技术性导致膨胀,更多的错误,并且通常是开发/维护成本的4倍.
因此,您需要认真考虑您的用户群.
我认为Alex Papadimoulis的文章非常有见地:http://thedailywtf.com/articles/soft_coding.aspx
它并不全面,但他有一些好处.
关于何时不使用规则引擎的伟大文章......(以及何时使用规则)....
http://www.jessrules.com/guidelines.shtml
另一种选择是,如果您有一组线性规则,只能以任何顺序应用一次以获得结果,即创建一个groovy接口并让开发人员编写和部署这些新规则.它的优点是速度快,因为通常你会通过hibernate会话或jdbc会话以及任何参数,这样你就可以以有效的方式访问所有的应用数据.使用事实列表,可能会有很多循环/匹配真的会降低系统速度.....这是避免规则引擎并能够动态部署的另一种方法(是的,我们的groovy规则部署在一个数据库,我们没有递归......它要么符合规则,要么没有.)这只是另一种选择.....哦,另外一个好处是没有为传入的开发人员学习规则语法.他们必须学习一些groovy,但这非常接近java,所以学习曲线要好得多.
这真的取决于你的背景.规则引擎有它们的位置,如果你有一个项目的规则,你可能想要为非常简化的情况(不需要规则引擎)动态部署,上面只是另一种选择.
基本上不要使用规则引擎,如果你有一个简单的规则集,而且可以有一个groovy接口......就像动态可部署一样,加入你的团队的新开发人员可以比drools语言更快地学习它.(但这是我的看法)
根据我的经验,当以下情况属实时,规则引擎效果最佳:
为您的问题域定义明确的学说
高质量(最好是自动化)数据,以帮助驱动大部分输入
访问主题专家
有创建专家系统经验的软件开发人员
如果缺少这四个特征中的任何一个,你仍然可能会发现一个规则引擎适合你,但每次我尝试过甚至一个缺失时,我都会遇到麻烦.
京公网安备 11010802040832号 | 京ICP备19059560号-6 