在我们的印象中,我们感觉规则引擎就是解决业务逻辑层的实现问题的。因此我们理所当然的觉得工作流中的某个节点的逻辑处理,应该可以用规则引擎来解决,那么工作流本身的逻辑也应该可以由规则引擎来解决。另外我们也会觉得,平时项目当中的业务逻辑应该都可以用规则引擎来解决。
但是当我们在使用上述这些规则引擎,却发现很难和我们实际应用的业务逻辑层的业务逻辑实现相对应。
我们以JBoss的Drools为例,由于其规则引擎使用了匹配规则的方式来进行,因此在应用这些规则引擎时。首先需要将我们具体应用中的业务逻辑做抽象,抽象成一条条规则之后,再打包成一个规则包。一个规则包相当于一个智能块。当数据传递给这个智能块后,系统会以匹配的方式应用满足条件的逻辑处理。
当采用这种方式时,应该说逻辑更抽象了,在一个更高的层次加以抽象化的定义。但是也使得规则引擎的应用得到了很大的限制。
首先这种抽象本身需要一个复杂的分析过程,这需要有很强的分析设计能力。另外我们平时具体应用中的业务逻辑层,大量的逻辑都是对实际数据的处理,很多时候还是一个批量数据的处理,甚至有些逻辑需要的参数我们并不能定义在规则中,而是在数据库表中进行配置。因此我们常见的业务逻辑层的开发,并不能先设计出一个数据模型,然后再在此基础上抽象逻辑。
因此我们发现Drools等规则引擎很难用,根本不是我们所需要的那样。
我们研究规则引擎也有一段时间了。有时候我们发现自己做的规则引擎并不是一个规则引擎。因为我们和像Drools这些规则引擎有很大的差别。但我们确实解决了业务逻辑层的业务逻辑配置问题。应该说我们的更实用一些。但是我们却没法去实现JSR94标准。我们不光处理业务逻辑,还把所有业务逻辑层需要处理的 *** 作全部采用规则配置的形式,包括数据库处理逻辑等。
旗正规则引擎通过数据库配置器(DataBuilder)来管理数据库,无论是Oracle,还是其他主流的数据都支持, *** 作方式是一样的。旗正规则引擎的数据库配置器是用于编辑数据库结构信息以及管理数据库表数据,并且可以执行SQL 语句,主要功能如下。
1)数据库生成表结构信息:
主要生成数据库配置文件(.conf文件),用于规则编辑器调用数据库 *** 作代码.
2)添加功能:
添加表,添加视图,添加存储过程,以及添加查询
3)处理表结构信息:
导入表结构信息,更新表结构信息,删除表结构信息
4)编辑表数据。
编辑表中数据,更改表中字段显示名称,更该表字段类型
5)执行 SQL语句。
主要满足对表中数据进行查询,插入,更新,删除等数据库 *** 作。
连接Oracle如下所示
1、打开数据库配置器,选择菜单栏---》新建,然后选择:从Oracle数据库导入
2、在d出的对话框中填入相对应的信息,点确定
3、选择需要用的数据库表,也可全选,点确定
4、点击上方的保存按钮
5、将*.dbs文件保存到电脑中,后续规则引擎中需要连接数据库,即可将该dbs文件导入到规则包的对象库中
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)