什么是drools?
     Drools 是一个基于Charles Forgy's的Rete算法的,专为Java语言所设计的规则引擎。Rete算法应用于面向对象的接口将使基于商业对象的商业规则的表达更为自然。Drools是用Java写的,但能同时运行在Java和.Net上。      何时使用规则引擎?
1.如果业务逻辑代码包括很多 if-else 语句,则应考虑使用一个规则引擎。维护复杂的 Boolean 逻辑可能是非常困难的任务,而规则引擎可以帮助开发人员组织该逻辑。
2.使用声明方法而非命令编程语言表达逻辑时,变化引入错误的可能性会大大降低。
3.如果代码变化可能导致大量的财政损失,则也应考虑规则引擎。许多组织在将已编译代码部署到托管环境中时具有严格的规则。例如,如果需要修改 Java 类中的逻辑,在更改进入生产环境之前,将会经历一个冗长乏味的过程:
     必须重新编译应用程序代码。
     在测试中转环境中删除代码。
     由数据质量审核员检查代码。
     由托管环境架构师批准更改。
     计划代码部署。即使对一行代码的简单更改也可能花费组织的几千美元。如果需要遵循这些严格规则并且发现您频繁更改业务逻辑代码,则非常有必要考虑使用规则引擎。
4.维护方面,业务规则和业务层分离,后期若业务规则发生更改,则不用修改java代码,只需修改规则列表.以至于无需开发人员维护.
5.rhs这里可以写纯java代码,也可以调用静态方法&操作数据库.即,规则列表内可以实现业务逻辑.Drools使用中的部分缺陷:
1、数据准备工作量大。在将一些数据进行处理时,需要准备大量的已经计算好的数据。这样的话,像数据过滤逻辑、预处理逻辑、数据转换逻辑、存取数据逻辑等就必须采用编写程序的方式来进行。工作量很大。
2、数据结构变化时,不能像规则一样动态变化。规则引擎使用的目的是为了企业系统将来在修改业务规则时,不再需要去修改程序。但是采用rete算法,使得只有规则能够动态变化。而数据结构的变化却不能,因此这限制了规则引擎的应用。
3、规则语言编写太多专业。规则语言其实比写java代码简化不了多少,编写规则的门槛较高。
4、消耗资源多,性能较差:采用rete算法的规则引擎在处理共享的资源时,消耗资源太大。性能比较差。
以上介绍,关于drools优缺点(欢迎补充),现在在设计一款手游的规则列表。为了便于开发。我想使用drools想把大量的逻辑判断从业务中分离出来。以至于后期维护无需开发人员,定义什么规则,直接让策划修改xml文件。但是资料上说,drools适用于应用服务器,不适用于移动设备大家,怎么看?欢迎补充drools优缺点。欢迎大家给积极的意见。或者还有什么别的方法实现逻辑判断和业务分离。欢迎补充~~drools

解决方案 »

  1.   

    规则引擎可以配置,但不限于Drools。
    我们项目是用xml做得。
    正则表达式作为规则
      

  2.   


    规则引擎 不仅仅限于Drools,我们是采用这种方式来实现的1:在规则中集成数据库操作,这样准备数据的工作也就可以再规则中完成,其次当数据结构发生变化时,在规则中同样可以随之改变,能变的不仅仅是业务逻辑。
    2:采用自然语言来编写配置规则,这样使得业务人员更容易理解,也能参与到规则的配置中