Drools能做什么，什么时候使用它

   大多数网络及企业级Jave应用可以分为三部分：和用户交互的前端，和后端系统（比如数据库）交互的服务层和这两部分之间的商务逻辑层。通常使用框架（像Struts, Cocoon, Spring, Hibernate, JDO, 和实体Beans）可以实现前端和后端的功能，但对于商务逻辑层却没有一个标准的构建方法。像EJB和Spring只能在高端实现商务逻辑构建，但却不能组织代码。如果我们使用在配置性，可读性和重用性方面带我们极大利益的框架代替那些纷繁复杂的if...then语句，那不是很好吗？

       下面的代码是我们试图避免的问题的例子。说明一个典型Java应用中的一些商务逻辑。
        if ((user.isMemberOf(AdministratorGroup)
               && user.isMemberOf(teleworkerGroup))
               || user.isSuperUser(){      
                // 更多对特殊案例的检查
              if((expenseRequest.code().equals("B203")
                         ||(expenseRequest.code().equals("A903")
                        &&(totalExpenses<200)
                       &&(bossSignOff> totalExpenses))
                       &&(deptBudget.notExceeded)) {
               //付款
           } else if {
               //检查许多其他的条件
           }
      } else {
           //更多商务逻辑
      }

    我们都曾经历过相类似或者更为复杂的商务逻辑。当试图在Java中采用标准方法来实施商务逻辑时，就有很多问题随之而来。

    如果商务人员提出需要在本已很难理解的代码中加入另外一个表单（"C987"）怎么办？一旦所有的最初开发人员都在开发中，你愿意成为一个维护人员吗？

·        如何确认这些规则的正确与否？对技术人员来说（从来不关注商务人员），检查规则的正确性是非常困难的。那么，有什么方法论来测试商务逻辑那？

许多应用有着类似的商务逻辑。如果其中一个规则发生了变化，我们能够确认所有系统中的相关部分都要改变吗？如果一个新应用使用了一些规则，但是也加入了一些新规则，我们需要彻底重写逻辑吗？

·        商务逻辑嵌入在Java代码中，每次哪怕是很小的改变都需要再编译/再部署这些代码，这些商务逻辑容易配置吗?

·        如果其他的（脚本）语言想平衡现有投资在商务规则逻辑中怎么办？

J2EE/EJB和倒置控制的框架（像Spring, Pico和Avalon）让我们有能力在高端组织代码。他们很提供很好的重用性，配置性和安全性，但却不能替代上面例子中的“意大利面条式代码”。理想地，无论我们选择那个框架，不仅要和J2EE应用，而且要和通常Java编程(J2SE—标准版本)及广泛使用的表现和持续性框架相一致。这种框架让我们能够做到：

·        商务用户很容易的读和验证商务逻辑。

·        在应用中，商务规则是可重用的和可配置的。

·        在重负荷下，框架是可扩展的和性能良好的。

·        Java编程人员对已存在的前端（Struts, Spring）和后端框架（对象关系映射）很容易使用这种框架。

 

另一个问题是在不同的应用中，组织页面，数据库访问和商务逻辑的方法也是多种多样的。我们的框架能够处理这个问题，并能始终提升代码的重用性。理想地，我们的应用使用“适用所有方式的框架”。以这种方式使用框架，能够让我们许多的应用构建的更好，让我们可以仅关注那些对用户更有价值的部分。

 

规则引擎的营救

如何解决这个问题那? 一个解决方案是使用规则引擎。规则引擎是组织商务逻辑的框架。它让开发者集中精力在他们有把握的事情上，而不是在一些低级机制上作决定。

通常，商务用户对那些能让他们理解是正确的事情感到更加舒服，相对于那些诸如用if...then 形式来表达的事情。你从商务专家那里听到的一些事情如下

·        “10A表单用于申请超过200欧元的花费.”

·        “我们仅对数量1万或超过1万的交易提供分成.”

·        “超过10m英镑的采购需要公司总监的批准.”

通过关注于商务用户知道是正确的事情上，而不是怎样用Jave代码来表达它，上面的说明比以前我们的代码例子要清楚的多。尽管他们已经很清楚了，我们仍然需要一种机制，将这些规则应用到商务用户已知和作决定的事实中去。这种机制就是规则引擎。

我什么时候应该使用规则引擎？

“如果你有一把锤子，那所有的东西都看起来都像钉子”，这句话在软件工程领域几乎成了陈词滥调了。虽然规则引擎能解决我们的许多问题，但确实值得认真考虑一下规则引擎对我们的企业级Java应用是否合适。需要问的问题有：

 

● 我的应用程序有多复杂?对于那些只是把数据从数据库中传入传出，并不做更多事情的应用程序，最好不要使用规则引擎。但是，当在Java中有一定量的商业逻辑处理的话，可以考虑Drools的使用。这是因为很多应用随着时间的推移越来越复杂，而Drools可以让你轻松应对这一切。

 

● 我的应用的生命周期有多久？这个问题的正确答案往往是“令人惊讶的长”――还记得那些认为他们的程序不会苟活到2000年的大型机的程序员吗？使用规则引擎将会在中长期得到好处。像这篇文章所展示的那样，甚至原型都能从Drools与灵活方法的组合中获益，让“原型系统”转化成生产系统。

 

●      我的应用需要改变吗？唯一能确定的是你的需求将会改变，无论是在开发过程中或是在开发完成以后。Drools使用一个或多个简单易配的XML文件帮你来应对这一切。

●       

那么性能呢？

如果你正在写一个企业级应用，很有可能它会扩展到成百（如果不是成千）的用户。你已经知道现有的Java和J2EE应用能做到这一点，但一个使用了Drools的应用对这一压力的表现如何？答案是：“令人吃惊的好”。大多数开发者只是因为不愿“失控”而依赖于他人的代码（比如：某种框架），想想这个：Drools不仅可以让你的应用和“传统”的编程方法一样快，甚至可以更快,看下面：

 

● 避免糟糕的代码：Drools引导开发者去做“正确的事”。你可以确定你正在写的代码是好的，但你的开发伙伴呢？你可以同样这样说吗？使用框架可以让你更轻松地写出更快，更好的代码。

 

● 优化过的框架：你有多少次看见商业逻辑重复地从数据库中提取相同的信息，从而降低了整个应用的速度？如果正确使用的话，Drools不仅仅能够记住信息，而且还能记住以往使用该信息进行测试的结果，从而大幅提升应用的速度。

 

● Rete算法：很多次我们并不是真正需要使用“if”条件。被Drools实现的Rete算法，可以用一个优化的方法替换掉所有的“if…then”表达式。需要重点提及的是：Rete算法在使用更多的内存来降低运行时延迟方面作了折衷。当然这在现代的应用服务器中并不是一个问题，我们也并不推荐你在移动手机上使用Drools!

原文：http://www.matrix.org.cn/resource/article/43/43782_Drools.html

           http://www.matrix.org.cn/resource/article/44/44046_Drools+Framework+Business.html