转载

【原创】为什么要用规则引擎?

一天,朱斯参加了一场code Review研讨会。会上的一群人正在讨论着如何对祖传代码进行变更,大家你一言,我一语,场面十分热闹!

突然,只见人群中的一个人满面愁容,说道:"昨天在项目中看到下面这样一段代码,分支太多了!维护起来很烦啊!"

if(day == "周一"){
  System.out.println("I will play basketball");
}else if (day == "周二"){
  System.out.println("I will do shopping");
}else if (day == "周三"){
  System.out.println("I will wash clothes");
}else if(...) {
    ...
}//很烦,写不下去了

研讨会上的另一个人提道:"这个容易啊,可以用策略模式来简化if else的结构!毕竟策略模式强调的就是数据与业务逻辑分离,针对每一个分支写一个策略就好啦!"

可是,旁边的一个人说道:"用策略模式来简化if else的代码结构固然可以,但是这里有一个前提,就是分支比较少,一般就十来个分支差不多了,可以用策略模式来简化!但是如果我有上万个分支呢?你难道做上万个策略?就算这几万个策略真给你写出来了,你以后怎么维护?以后要修改策略,改完再重新部署一次么?太不灵活了啊!"

此时,刚好有一位DBA大神也参加了这场code Review研讨会!他说道:"要不考虑一下存储过程?将变化的策略放在存储过程里维护,这样至少修改了策略,不用部署原来的应用!"

听到这里,朱斯实在听不下去了,猛的回了一句:"不行!不行!用存储过程可读性更差,而且性能还不好!更可怕的是,如果你用的是MySQL,调试存储过程是会要人命的!"

"唉,这也不行,那也不行,究竟该怎么办?"人群中充斥着吵闹声!

朱斯摆了摆手,示意大家静静,说道:"我们需要明白现在的需求是什么?

  • 第一,我们要简化if else结构,让业务逻辑和数据分离!
  • 第二,分离出的业务逻辑必须要易于编写,至少单独编写这些业务逻辑,要比写代码快!
  • 第三,分离出的业务逻辑必须要比原来的代码更容易读懂!
  • 第四,分离出的业务逻辑必须比原来的易于维护,至少改动这些逻辑,应用程序不用重启!
    大概,就上面四点吧!"

大家问道"有满足这样需求的中间件么?"

朱斯说道:"有的!那就是规则引擎!在一些强大的规则引擎中,可以像下面这样优化,使数据和逻辑分离!"

朱斯补充道:"像上面这张图这样,我们将业务逻辑抽取到单独的规则文件里进行维护,实现了业务和数据分离!至于数据如何传入规则引擎呢,注意看代码里有一句叫kieSession.insert("星期一"),这样规则引擎就知道自己有一个字符串内容为星期一的入参!而且,大家注意看哦,规则文件内容是可以用中文编写的!"

"哇塞、还能用中文来表述业务逻辑!这样非技术人员也能看得懂呀!"人群中传来一阵惊叹声!
(ps:笔者的同事,当年第一次见到我写的中文业务逻辑,他一脸的神奇!~)

朱斯补充道:"不仅如此,当你新加一个条件分支的时候,直接新增一个规则文件就好啦!例如,我们要多加一个判断周二要去shopping!那我们就在规则包中新增一个文件,内容如下!"

rule "test92"
    when
        如果今天是星期二
    then
        我要去购物  
end

"大家看,我们在规则包中新增上述规则文件后,你只要让你的应用程序从新加载一次规则包就好啦!完全不用重启原来的应用程序!"朱斯说完话,面带笑容的看着大家。

众人看着朱斯的讲解,纷纷称奇!

突然,人群中一阵沸腾,问道"哇哇哇,真是太神奇了,快告诉我们这套规则引擎叫啥!"

"我叫朱斯(Drools),刚才展示的那套规则语言是我的领域特殊语言(DSL)!"

正文到此结束
本文目录