规则引擎集成数据库操作

在一般 的 项目 开发中，用的最多的是基于 数据库的 管理 系统，虽说现在对关系型 数据库出来了很多的替代 方案，但是在实际正式的项目中，我们基本上还是使用关系型数据库来进行开发。
    在项目开发的过程中，我们主要是抓住几个关键的地方。一个就是数据库结构的设计，以及操作该数据库的SQL语句。虽说现在Hibernate等可以不用再书写SQL语句来进行开发，但是对于高级设计人员来说，SQL语句还是最简洁和快速的开发方法。书写一个复杂一些的SQL语句，可以极大的提高 性能和减少开发工作量。
     第二个关键的地方是对数据的处理逻辑，现在做系统喜欢组件化、 服务化。就是说我一个服务，或者说一个数据处理逻辑，我可以开放不同的接口供不同来源的 客户端调用。比如可以通过HTTP提交的方式来调用，可以通过 SOAP的服务来调用，可以通过Ajax的提交来调用，可以通过SOCKET通讯来调用等等。因此保证数据处理逻辑的正确稳定，是最关键的，这个涉及的系统的安全性和稳定性。
     第三个关键的地方就是 用户操作界面，用户操作界面目前用的最多的还是DHTML和 Javascript，当然有些 应用中用到Flex等 技术，但相对应用还是比较少。用户操作界面的改进要求，表面上看是最不重要的，但是确实用户最关心的，也是用户意见最大的地方，也是最消耗 程序员工作量的地方。
    现在的系统开发，不希望重复制造轮子，因此有很多现有的技术可以用。比如在数据库层，用了Hibernate或者IBatis等，在 业务逻辑层，用到Spring，Struts等，在前端界面层用到了Ext，JQuery等。
     但这些只是一些底层的框架，在此基础上，还需要在封装一些平台或者组件。现在主流的就是工作流平台。目前的工作流很多时候，已经不完全是专门为工作流服务的了，都或多或少带了一些快速开发平台的功能。因为在做工作流的过程中，除了处理了核心的流程控制、权限控制、表单设计、数据结构之外，都会觉得其实大部分的应用开发，都可以采用工作流的这些表单设计以及流程控制来走。因此就在此基础上，扩展了相应的功能。
    但是由于工作流主要侧重在于流程的控制，当很多应用都通过工作流引擎来处理时，发现性能是个很大的瓶颈。或者说有些功能，工作流实现起来非常麻烦，又要扩展工作流，使得功能变得太复杂，难以维护。
    因此在工作流平台的实现中，就会希望将一些非流程控制的部分，和流程控制部分分离出来。这就是规则引擎的初衷，希望规则引擎能单独处理非流程控制部分，并且处理好性能。
    但是目前主流的一些规则引擎其初衷并不是去处理这些部分，而是管理复杂、雷同、数据结构稳定的业务规则。因此只有在规则引擎中集成了数据库操作，才能满足工作流引擎中，处理非流程控制部分。
    要实现在规则引擎中集成数据库操作，首先必须使得数据库层是动态的。比如像现有的Hibernate等就不能支持动态的特性，因为Hibernate需要根据XML说明需要重新生成Java类，而这些类的应用必须重新启动 服务器。因此首先需要开发一批能够动态变更的数据库层。在此基础上，在规则编辑器中，增加对数据库结构的动态获取支持，也就是说可以直接去读取数据库中的表结构等，对应的得到相应的数据库层。
    只有在这两个基础上，规则引擎集成数据库层才真正有用。规则引擎来实现业务逻辑控制时，才真正的体现出大量的节约的开发工作量，也使得业务逻辑层的实现变得简单。
    这样，就可以将更多的精力集中在数据库结构的设计以及用户操作界面的改进。