package 包路径名 // 包名必须定义的,必须放在规则文件第一行,经测试发现,需要和drl文件的存放路径保持一致
import XXX // 导入规则文件需要用到的外部规则文件、变量、类、类中的静态方法
rule "规则名"
// (属性部分,定义属性、设置规则执行的参数等)
salience 100
when
// 条件部分(条件可以单个,也可以多个,多个条件则写多行,多个条件之间可以是and也可以是or的关系)
// (满足什么样的条件),也叫作规则的 LHS(Left Hand Side)
then
// 结果部分
// (得到最终动作/结果),也叫作规则的 RHS(Right Hand Side)
end
获取KieServices -> 获取KieContainer -> 创建KieSession实例 -> 插入事实 -> 触发规则 -> 关闭KieSession
①. 规则拆分原则:将规则进行拆分,避免出现OR的情况
②. 规则比较原则:将区间或模糊查询的方式排在比较值的后面
③. 规则简单原则:尽量避免出现过于复杂比较值
④. 规则结果原则:then中避免出来if eles
①. 同一类型的对象/同一个JAVABEAN对应的规则,尽量放在一个规则文件里。这样做的好处是:当WorkingMemery的fact对象变化时,可以控制规则的触发条件。 同时,该对象的所有规则在同一个文件,也方便维护;
②. 每条规则语句,最好都加上salience属性;
③. 每条规则执行结束,都应该加上打印日志的静态方法,此方法应该统一封装提供;
④. 所有的规则文件(.drl)应统一放在一个规定的文件夹中,如:/rules文件夹
⑤. 书写的每个规则应尽量加上注释。注释要清晰明了,言简意赅
⑥. 规则结果部分(RHS)尽量不要有条件语句,如if(…),尽量不要有复杂的逻辑和深层次的嵌套语句
⑦. Drools默认dialect为"Java",尽量避免使用dialect “mvel”
⑧. 规则中条件字面量有==这样的比较符,要把这中最严格的放到前面所有条件的最前面
⑨. 在推理部分(LHS)不推荐使用if … then这样的条件判断语句,应该是明确的行为,因为条件判断应该在LHS中就已经明确区分出来了,如果推论部分存在条件判断的话,应该增加新的规则以满足业务需求。