规则引擎

规则引擎

【一、什么是规则引擎】

    规则引擎这个词在百度上有非常宏大的定义，即“实现了将业务决策从应用程序代码中分离出来，它接受数据输入，解释业务规则，并根据业务规则做出业务决策”，好生抽象啊，好在我所期望的规则引擎无需那么的高大上。最近在思考如何抽象一个 简易的工作流引擎，在单条串联式的流程中毫无压力，比如“小李申请请假-->项目经理审核”大概就结了，而在类似“分支”判断的情形时，竟如鲠在喉，有一个问题无法释怀“如何在工作流运行时动态地 根据用户的输入值来判定流程的流转方向？”，比如“小张请假天数为两天之内就按正常流程走，而如果请假天数在三天或三天以上，则需要进一步提交到总经理进行审核”，大家有碰到过这个问题吗？显然，流程的流转是由小李所填写请假单的 天数来决定的。如果我的应用程序是“写死的”，写个“if-else”也就解决问题了，但是现在问题已升华到“引擎”了，不可能去写基于 C#或Java 的判断语句了，一开始在思考这个问题时，我幻想“把 if-else 语句想办法存在配置文件或SQL数据库里，当程序运行时再拿出来运行”，行文至此，仍不免一笑，C#或Java 作为编译型语言怎么可能“拎起来”就执行，以现在的眼光看问题是可笑的，但思路却由此打开。

 

【二、我所理解的规则引擎是什么】

    了解到行业性的规则引擎概念以及我自己的切身使用场景后，我最想要的规则引擎也就清晰了。在摸索的过程中，先后学习了 Drools.NET( 官网, 教程) 和 NxBRE( 教程)，这两个开源规则引擎很完善、很宠大，它们能解决我的问题但显臃肿，我需要的是轻量级，我只不过是“想在运行时执行一个业务逻辑判断，然后返回一个值”就可以了，期间我考虑使用 IronPython，转悠一圈发现开发成本相当大，继续寻找，于是“ A2D-Framework REngine(Github)”走进了我的视线。

 

【三、它在工作流引擎中是起什么作用的？】

    REngine 很轻便的解决了我一直头疼的问题，它是在(.NET C#)运行时通过执行 JavaScript 引擎来获取一个结果，进而反馈给 C#。

    哎呀，当问题得到了合理的归类分化，世界一下子透明了许多！

    方案在手，紧接着我规划如下：C#只需要关心流程的流转，再配以持久层存储到数据库即可，至于工作流该如何流转、流转的条件是什么（比如：请两天假就按正常流程走，请三天假则另需总经理首肯），这些问题统统交由 规则引擎 REngine 来处理就好，REngine 的核心是一个 JavaScript 引擎，它可以接受一切的“合乎 JavaScript 语言规范”的文本，通过 JavaScript 的即时解释特性以达到运算的目的，这提到的“文本”就是 REngine 引擎所需的 规则文件，它以“ .rule”为后缀名，怎么理解这个规则引擎的工作机制呢？它与控制反转 Ioc 可作同一类比：REngine 引擎与其规则文件，就如同 Ioc 与其 XML 配置文件是一样一样儿的，当规则有变时，就像 Ioc 中接口的实现有变更，只需改一下新的对应实现类就可以。

    显然，规则的变更，瞬间就提升到了配置化的层面，为工作流引擎、为项目的高维护性注入了信心。

 

【四、简介 Aaron 的规则引擎】

规则引擎 REngine 系 Aaron 的作品（ 去博客园了解他）。

REngine 的规则文件（.rule）形如：

#region 请假规则
    rule default
        return  "" ;
    end rule

    rule AskForLeaveFork
        if (Leave <= 2)
            return  "toLeader" ;
        else  if (Leave > 2)
            return  "toGeneralManager" ;
    end rule

#endregion

 

如果这个工作流引擎移到另一个项目，根据他们的需求，发现请假天数的界限是 3 天，那直接把规则中的 2 改为 3 即可，如果判断规则有大的变化，那重新写 if-else 判断即可，只需要遵循 JavaScript 语言规范即可。

 

【五、总结规则引擎的好处】

    为工作流引擎在类似“分支”判断这样的场景编写业务规则，引导流程作出正确的流转；当规则有变更时，只需修改规则，或者在UI界面上修改也行，即存即用，这样 .NET 程序无需再编译、再部署。

 

此文仅作抛砖引玉，期待热衷工作流和规则引擎的朋友们留言斧正，感激不尽！