32-drools入门案例(开发实现_4)

刚才入门案例已经写完了，并且效果也已经运行出来了。接下来回到讲义来看一下。

通过上面入门案例可以发现使用drose规则引擎主要工作就是编写规则文件。在这花了一些时间来编写规则文件。在规则文件里边就是将业务场景下面所涉及到的业务规则通过特有的语法来表现出来，但是具体的语法后边会详细去讲解。

主要工作就是编写规则文件。在规则文件中定义跟业务相关的业务规则。例如本案例中定义的是突出优惠的规则。定义好这些规则后就需要来调用drose提供的api将数据提供给规则引擎来进行模式匹配。

在这是通过单元测试这种方式调用了相关的api，比如有提供的kei service，还有kei container容器，还有session，这些都属于模板化的代码，就跟前面讲gdpc是非常类似的，都是模板化的代码。

拿到三神之后是不是需要给规则引擎传递相关的一些数据？原始数据。在这使用到的是outer对象来封装的，把原始的价格，就是优惠之前的图书价格给传进去。传进去之后由规则引擎自动进行模式匹配。规则引擎会执行匹配成功的规则并将计算结果返回给我们。

它是通过什么样的方式把结果返回给我们？大家可以看到在规则文件里面，比如如果是第一个规则出发了，这样就会在这个镇这块来执行这样的代码。在这可以看到是不是设置了order对象，而order在规则文件里面只是一个对象的引用，其实指向的是谁？指向的就是传进去的outer对象。

outer对象大家可以看到在规则真正出发之前是不是在这输出了一下？这个时候因为在newalt对象的时候并没有去设置real price，就是优惠后的价格。所以在输出的时候大家可以看到它是不是闹？它是闹。

而当执行完这句话之后，这句话的作用就是进行模式匹配。如果匹配成功规则引擎会执行规则，执行规则之后是不是就会在这来设置real price？所以在这句话执行完成之后再来输出order对象的real price，它是不是就能够获取到相关的值了？其实是通过对象引用这种方式将结果反馈给应用程序，这是将计算结果反馈给我们，并不是通过返回值那种方式，而是通过传进去的对象，就是传进去个out对象。

在规则文件里边是不是去修改out对象，在应用程序里边是不是还可以根据out对象来获取相关的值，而这个值就是设置之后的值，在规则文件里面设置之后的值。

可能大家这块会有一些疑问，虽然并没有在代码里边是不是去编写这些逻辑判断ef else这些逻辑判断，但是是不是在规则文件当中编写了这些东西，这个跟在代码当中来编写这些逻辑有什么本质的区别？

估计很多人可能会有这样的疑问，就是在代码里边确实是没有去写ef else各种判断，但是规则文件是不是描述的也依然是ef else这些信息，无非就是换了个位置，把原先这个代码里面这些逻辑拿到了drl规则文件里面来，这个有什么本质的区别吗？

在这需要再来说一下，前面已经提到了使用规则引擎，它的业务规则做到可以做到动态管理，就是可以把ef else这些规则判断的逻辑单独抽取出来，抽取到规则文件里面去，当然也可以抽取到其他文件里面，只不过用的比较多的是官方提供的这种后缀是drl的文件，把这些业务规则配置进来，而且这些东西是可以动态来管理的。

可以把这些规则看成数据，就可以像管理数据一样对这些规则来进行管理，比如可以查询这些规则，可以添加规则，可以更新规则等等这些，这样可以做到在不重启服务器的情况下来调整这些业务规则。

这块可以做一个类比，以前使用gb b c的时候是不是把那些soco语句全都写到谷歌代码里面去了，这样如果搜狗调整起来是不是并不是很方便，而后边是不是讲了买vitis框架是不是可以将这些搜狗语句统一抽取到谷歌代码里边来统一进行配置，而这个地方跟它是有点类似的，只不过抽取出来的并不是搜狗文件，而是这些业务规则，就是原先散落在谷歌代码里面那些efls这些逻辑判断规则，把它抽取到这个文件里面统一管理，并且也有相应的api对这些规则来进行动态的管理。

这就是使用规则引擎相对于原先传统的使用方式的优势。