規則引擎
【一、什么是規則引擎】
規則引擎這個詞在百度上有非常宏大的定義，即“實現了將業務決策從應用程序代碼中分離出來，它接受數據輸入，解釋業務規則，並根據業務規則做出業務決策”，好生抽象啊，好在我所期望的規則引擎無需那么的高大上。最近在思考如何抽象一個
簡易的工作流引擎，在單條串聯式的流程中毫無壓力，比如“小李申請請假-->項目經理審核”大概就結了，而在類似“分支”判斷的情形時，竟如鯁在喉，有一個問題無法釋懷“如何在工作流運行時動態地
根據用戶的輸入值來判定流程的流轉方向？”，比如“小張請假天數為兩天之內就按正常流程走，而如果請假天數在三天或三天以上，則需要進一步提交到總經理進行審核”，大家有碰到過這個問題嗎？顯然，流程的流轉是由小李所填寫請假單的
天數來決定的。如果我的應用程序是“寫死的”，寫個“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）形如：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
#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 程序無需再編譯、再部署。
此文僅作拋磚引玉，期待熱衷工作流和規則引擎的朋友們留言斧正，感激不盡！