我正在做一些类似于你想做的事情。
由于这些业务规则通常由业务部门执行,因此我希望业务部门通过 GUI 对规则进行必要的更改。
警告 警告 警告!!!一个常见的误解是,只要有GUI,非程序员就可以使用它。那是。。。不是我得出的结论。这很有帮助,但编程的困难部分不是编写代码,而是为正确的问题提出良好的解决方案。我敢肯定,一些更聪明、更懂技术的商业人士可以与Guvnor一起做事,但不要指望它会是通往神奇幸福之地的某种黄砖路。你仍然需要为业务人员提供一个理智的数据模型和API,让他们做他们需要的事情,但可以防止他们意外地做他们不想做的事情。
1. Drools是否支持轻量级GUI来编辑规则?
2. Drools Guvnor是一个轻量级的GUI,还是有没有办法让它降级?
好吧,“轻量级”是讨论的主题,但是Guvnor工作得很好,只需要一个浏览器,所以我认为这是可以的。
3. 将应用程序集成到Guvnor以阅读规则的难易程度如何?
好吧,一旦你启动了Guvnor并运行了,连接你的应用程序以使用连接到Guvnor并监听新的规则更新并不是特别困难。KnowledgeAgent
不幸的是,一般的Drools,特别是Guvnor有一堆怪癖,你可能不得不解决(例如,你必须分解Guvnor WAR文件并在WEB-INF /beans中编辑文件.xml设置非默认配置...)。但是一旦你理顺了这一点,我认为它效果很好。
至于文档,Javadocs有时可能有点稀疏,但该网站有一些相当不错的东西,包括几本书。
总而言之,Drools和Guvnor是强大的工具,但让它们工作并非易事。如果你真的需要他们提供的东西,他们是值得的,但如果一个更简单的脚本解决方案就足够了,也可能值得考虑。
现在,如果你发现自己真的需要Drools,这是我的首要建议 - 为你的数据库和规则保留单独的数据模型。这确实意味着有很多无聊的转换代码要写,但这是值得的。
我正在开发的应用程序将JPA用于数据库事务,在我们的规则中使用该数据模型并不是很愉快。有几个原因:
适合您的数据层的不一定适合Drools,反之亦然。
我们有一个树结构,在JPA中,它自然是与父节点列表中的子节点的关系。在Drools中使用列表是相当痛苦的,所以我们将其扁平化为一个结构,我们插入一个对象和一堆对象,这更容易使用。@OneToMany
ParentNode
ChildNode
敢于重构。
规则的数据模型也需要位于Guvnor内部 - 这意味着如果您重命名实体类或类似名称,则可以违反所有规则。规则的单独数据模型意味着您可以无后顾之忧地重构数据库内容。
向他们展示他们需要看到的内容。
数据库可能会变得相当复杂,但规则通常不需要关心其中的许多复杂性。向编辑规则的人员公开这些复杂性可能会导致许多不必要的混乱。例如,我们发现,对于我们的场景,绝对没有必要将规则编写者暴露给多对多关系(事实证明,在Drools中处理起来非常复杂) - 所以我们使它们看起来像一对多,一切都变得更加自然。
保护。
我们设计了大部分规则,使其像以下伪代码一样工作:
rule "Say hello to user"
when
user : User
then
insert(new ShowMessageCommand("Hello " + user.getName() + "!"))
end
...因此,对于每个规则包,可以清楚地定义可以插入哪些响应命令以及它们的作用。在应用中运行规则后,我们挑选出规则插入到会话中的对象并对其执行操作(访问者模式已被证明对于避免长 // 链非常有用)。if instanceof
else if instanceof
else
我很高兴我们以这种方式做到了这一点,而不是让规则编写者对我们的JPA对象做任何他们认为他们想做的事情。
无论如何,希望这有帮助。