规则引擎到底为什么需要规则匹配

最近参与到一些规则方面的项目模块，


也大概学习了一些主流规则引擎的资料。


谈谈我的一点想法和疑惑，


我的经验不多，是个木头脑袋。


热烈欢迎各位老大砸砖。


我不懂的问题是，规则引擎为什么需要把一堆规则扔到内存然后一个个匹配啊？（注意我的重点是为什么要“匹配”啊）


用若干if... then... else... then... 好端端的不能描述吗


我所接触到的项目做法是，对于一个内存对象所对应的规则集，我们把它集中到一个规则定义文件中。使用动态脚本语言来定义规则文件，也就是把那一堆if... then... else... then... 用脚本语言写好并指定预留参数，在运行时传参来实现规则的变化和定制。


可能这样的做法不能算是一个“规则引擎”


但是我觉得他能满足大多数实际应用。并且绝对轻量。


和主流规则引擎相比，我觉得似乎最大的差别就在于我们没有匹配，没有自动调用，需要手工指定规则执行顺序和优先级。


我想不通的就是


为什么要匹配啊

匹配是肯定需要的。

普通的if else这种条件判断在日益复杂的规则当中变的越来越难以维护了。
如果你的规则一点都不复杂那么使用规则引擎意义也不大。

那么请问


使用规则引擎之后我们能避免书写if... then... else... then... 这类东西吗


好像还是要写的吧


维护也还是要维护的吧


我没有一个感性认识


想请教下规则引擎到底怎样简化这些工作的

复杂的事情 总会是非常复杂的。

以Jboss的 drools来说吧。
它让你规则条理化，当然如果你很粗鲁的写一些规则，你没有很规划的去写规则，会发现你的drools文件会更加让人难以阅读。规则引擎其实也只是做了if else之类的东西，只不过它给大家更加直观的规则管理方式.

就说我们目前使用drools的背景吧：
网站上面大约有将近20种事件，每种事件都会有一堆的规则。而且规则都非常复杂，改动又比较大。客服可能会随时去修改一种规则的风险数值。那么传统的代码模式显然很难满足现状而且这些规则的逻辑也很难理清楚。
基于上面的现状后来开发了一套基于Jboss Drools规则引擎开发框架与风险处理系统。
针对每条规则设置一个风险值，如果一个事件匹配到一条规则其风险值进行累加，再根据最终的风险分数来决定对这种事件到底要采取什么措施.


凡是没有绝对。看哪些东西适合我们去用，采用一些最新的技术代价要多少、风险又有多少。

引入规则，原则上是希望把规则定义和规则处理进行解偶。
因为规则常常是无限的，多变的，
但是处理的方式是常常有限的。
按照理想的开发情况，项目上线后，就可以把规则维护交给运维人员，开发人员就可以托管了。
当然这个是理想情况，也是一开始的期望。不过现实中，规则语言的复杂度和运维人员的水平，一样可以把做开发的你带入地狱。