刷新工做流引擎价值观：规则引擎

【1、什么是规则引擎】

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

 

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

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

 

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

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

    哎呀，当问题获得了合理的归类分化，世界一会儿透明了许多！

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

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

 

【4、简介 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 语言规范便可。

 

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

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

 

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