drools-expert-docs52简体中文版

drools-expert-docs52简体中文版内容摘要：

由于规则引擎是动态的（可以存储和管理规则的意识动态的数据随时更新），他们往往是看着部署软件的问题的解决方案。 （大多数 IT 部门为防止正在推出的软件的目的似乎存在。 ）如果这 的原因是你想使用一个规则引擎，规则引擎的工作最好的，当你知道能写声明的规则。 作为一种替代方法，可以考虑数据驱动的设计（查 找表），或脚本处理引擎，在数据库管理脚本和能要更新动态。 脚本或流程引擎 希望前面的章节解释时，您可能要使用一个规则引擎。 替代是基于脚本引擎提供了“动态变化”的驱动器，并有许多这样的解决方案。 另外流程引擎（工作流程），如 jBPM 的允许您以图形方式（或编程）描述一个过程的步骤。 这些步骤也可以参与决策点这本身就是一个简单的规则。 流程引擎和规则往往可以很好地工作在一起，所以它们不是互相排斥的。 要注意与规则引擎的一个关键点是一些规则引擎是真正的脚本引擎。 脚本引擎的缺点是，你是紧密耦合的应用程序的脚本。 如果他们的规则，你有效地调用规则直接，这可能在未来造成更大的困难维护，因为它们往往在复杂的，随着时间的推移。 脚本引擎的好处是，他们可以更容易实施最初，迅速产生效果，和简单的概念为当务之急程序员。 很多人也实现数据驱动的系统，成功地在过去（那里控制表，这些存储元数据，改变你的应用程序的行为） 可以控制时可以保持非常有限。 然而，他们可以迅速成长的控制，如果延长太多（例如，只有原创者可以更改应用程序的行为）它们会导致应用程序停滞，因为他们太执着。 强和松散耦合 毫无疑问，你听说过“紧耦合”和“松耦合” ，在系统设计等方面。 一般人断言，“松”或“弱”耦合最好是在设计方面，由于增加灵活性，它可以提供。 同样的，你可以有“强耦合”和“弱耦合”的规则。 在这个意义上 说的强烈耦合意味着一个规则的“点火”，显然会导致另一个规则触发 等。 换句话说，有一个明确的（很明显）的逻辑链。 如果您的规则都 强耦合 的 ， 那么它们将会变得 不灵活 ， 明显看起来 规则引擎是一个大忽悠。 一个明确的链可以硬编码，使用 决策图表来执行。 这并不是说，强耦合本质上是不好 的，但有一点 要牢记当考虑一个规则引擎 通过 规则的方式捕捉。 “松散”耦合的规则 是指 当 一个系统规则发生 改变 时， 无需更改 、添加 、 删除 其他无关的规则。 规则执行原理 规则执行原理 规则执行顺序 以堆栈方式执行 ,优先级低的先入栈 ,同一优先级的 ,在规则文件中位置靠前的先入栈 . 例如： ?xml version= encoding=utf8? changeset xmlns= xmlns:xs= xs:schemaLocation= add resource source=classpath:sample/ type=DRL / resource source=classpath:sample/ type=DRL / /add /changeset 规则引擎会先执 行 规则文件中的规则 去匹配传入的参数，然后进入 中去匹配规则。 同一互斥组下 ,优先级高的如果 noloop true,则 ,此规则内如果插入新对象 ,视本规则为不匹配 ,执行下一规则 . 2 快速入门 无状态知识会话 那么我们从什么地方开始，在一个规则引擎中，比如诱人的 Drools，有这么多的用例和这么多的功能。 不用担心，我无畏的冒险者，复杂被分层，并且你可以用一个简单的用例让自己悠闲进入。 无状态会话，没有应用推理，构成了最简单的用例。 一个无状态会 话可以传给它一些数据，象函数一样被调用。 下面是无状态会话的通用用例，但不只限于此： 验证 这个人有按揭资格吗。 计算 计算按揭费用。 路由和过滤 过滤进入的信息，比如电子邮件，到一个文件夹中。 发送进入的信息到一个目的地。 那么让我们从使用一个驾驶执照申请的一个简单例子开始。 public class Applicant { private String name。 private int age。 private boolean valid。 // getter and setter methods here } 现在我们已有了我们的数据模型，我们可以编写我们的第一个规则。 我们假设应用程序使用规则来驳斥无效的申请。 因为这是一个简单的验证用例，我们将增加单条规则来限制任何年龄小于 18 岁的人。 package rule Is of valid age when $a : Applicant( age 18 ) then $( false )。 end 为了让引 擎知道数据，可以根据规则处理它，我们必须插入数据，多数人喜欢使用一个数据库。 当申请人（ Applicant）实例被插入到引擎内，根据规则约束计算它，在这个案例中，只有两个约束用于一条规则。 我们说两个是因为类型 Applicant 是第一对象类型约束，而 age 18 是第二个字段约束。 一个对象类型约束加上零个或多个它的字段约束作为一个模式（ patter n）被提交。 当插入的实例满足该对象类型约束和它的所有字段约束时，它被认为是匹配的。 $a 是绑定的变量，允许我们在结论中引用该匹配的对象。 在那儿可以更新它的属性。 美元符 $是可选的，但它有助于区分字段名和变量名。 根据插入的数据匹配模式的过程，常被称为模式匹配就毫不奇怪了。 让我们假设规则与类一样被放在同一个文件夹中，那么我们就可以使用类路径资源加载器来构建我们的第一个 KnowledgeBase（知识库），我们编译的规则的集合被称为一个知识库，使用 KnowledgeBuilder（知识构建器）编译它。 KnowledgeBuilder kbuilder = ()。 ( ( , getClass() ), )。 if ( () ) { ( ().toString() )。 } ( () )。 上面的代码，使用 newClassPathResource()方法，在类路径上查找 文件。 资源类型是 DRL（ Drools Rule Language）。 一旦 DRL文件已被添加，我们可以检查知识构建器 Knowl edgeBuilder 对象的错误。 如果没有错误，我可以添加结果包到我们的知识库。 现在我们准备构建我们的会话，并根据一些数据执行： StatelessKnowledgeSession ksession = ()。 Applicant applicant = new Applicant( Mr Jo。