使用规则引擎实现业务逻辑.docx

使用VisualRules规则引擎实现业务逻辑使用规则引擎可以通过降低实现复杂业务逻辑的组件的复杂性，降低应用程序的维护和可扩展性成本。这篇文章展示如何使用VisualRules规则引擎让 Java? 应用程序更适应变化。VisualRules有一个本地规则表达式语言和一个规则编辑器插件，使 VisualRules的应用更加简单快捷要求施加在当今软件产品上的大多数复杂性是行为和功能方面的，从而导致组件实现具有复杂的业务逻辑。实现 J2EE 或 J2SE 应用程序中业务逻辑最常见的方法是编写 Java 代码来实现需求文档的规则和逻辑。在大多数情况下，该代码的错综复杂性使得维护和更新应用程序的业务逻辑成为一项令人畏惧的任务，甚至对于经验丰富的开发人员来说也是如此。任何更改，不管多么简单，仍然会产生重编译和重部署成本。规则引擎试图解决（或者至少降低）应用程序业务逻辑的开发和维护中固有的问题和困难。可以将规则引擎看作实现复杂业务逻辑的框架。大多数规则引擎允许您使用声明性编程来表达对于某些给定信息或知识有效的结果。您可以专注于已知为真的事实及其结果，也就是应用程序的业务逻辑。有多个规则引擎可供使用，其中包括商业和开放源码选择。商业规则引擎通常允许使用专用的类似英语的语言来表达规则。其他规则引擎允许使用脚本语言（比如 Groovy 或 Python）编写规则。本文为您介绍 VisualRules规则引擎，并使用示例程序帮助您理解如何使用 VisualRules作为 Java 应用程序中业务逻辑层的一部分。更多事情在变化……俗话说得好，“惟一不变的是变化。”软件应用程序的业务逻辑正是如此。出于以下原因，实现应用程序业务逻辑的组件可能必须更改：在开发期间或部署后修复代码缺陷 应付特殊状况，即客户一开始没有提到要将业务逻辑考虑在内 处理客户已更改的业务目标 符合组织对敏捷或迭代开发过程的使用 如果存在这些可能性，则迫切需要一个无需太多复杂性就能处理业务逻辑更改的应用程序，尤其是当更改复杂 if-else 逻辑的开发人员并不是以前编写代码的开发人员时。VisualRules版本及特点描述VisualRules是用 Java 语言编写的商业规则引擎。VisualRules允许使用声明方式表达业务逻辑。可以使用独有的本地语言编写规则，从而便于学习和理解。并且，还可以将 Java 代码直接嵌入到规则文件中，这令 VisualRules的学习更加吸引人。VisualRules还具有其他优点：非常健全的技术支持 易用 快速的执行速度 规则编译为Java代码，跨平台 超过10年的专注研发投入 商业化的售后服务，使产生问题得到更好的处理当前VisualRules版本在编写本文之际，VisualRules规则引擎的最新版本是 4.0.7。这是一个更好的版本，它加入更多的功能和更简单的使用。例如，用于远程规则的部署和管理。本文展示如何使用VisualRules作为示例 Java 应用程序中业务逻辑层的一部分。设置虚拟场景下列假设为应用程序解决的虚构问题设置了场景：名为 XYZ 的公司构建两种类型的计算机机器：Type1 和 Type2。机器类型按其架构定义。XYZ 计算机可以提供多种功能。当前定义了四种功能：DDNS Server、DNS Server、Gateway 和 Router。在发运每台机器之前，XYZ 在其上执行多个测试。在每台机器上执行的测试取决于每台机器的类型和功能。目前，定义了五种测试：Test1、Test2、Test3、Test4 和 Test5。当将测试分配给一台计算机时，也将测试到期日期 分配给该机器。分配给计算机的测试不能晚于该到期日期执行。到期日期值取决于分配给机器的测试。XYZ 使用可以确定机器类型和功能的内部开发的软件应用程序，自动化了执行测试时的大部分过程。然后，基于这些属性，应用程序确定要执行的测试及其到期日期。目前，为计算机分配测试和测试到期日期的逻辑是该应用程序的已编译代码的一部分。包含该逻辑的组件用 Java 语言编写。分配测试和到期日期的逻辑一个月更改多次。当开发人员需要使用 Java 代码实现该逻辑时，必须经历一个冗长乏味的过程。 因为在对为计算机分配测试和到期日期的逻辑进行更改时，公司会发生高额成本，所以XYZ 主管已经要求软件工程师寻找一种灵活的方法，用最少的代价将对业务规则的更改 “推” 至生产环境。于是VisualRules走上舞台了。工程师决定，如果它们使用规则引擎来表达确定哪些测试应该执行的规则，则可以节省更多时间和精力。他们将只需要更改规则文件的内容，然后在生产环境中替换该文件。对于他们来说，这比更改已编译代码并在将已编译代码部署到生产环境中时进行由组织强制的冗长过程要简单省时得多。目前，在为机器分配测试