刷新工做流引擎價值觀：規則引擎

【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 程序無需再編譯、再部署。

 

此文僅做拋磚引玉，期待熱衷工做流和規則引擎的朋友們留言斧正，感激涕零！