一天，朱斯參加了一場code review研討會。會上的一群人正在討論著如何對祖傳**進行變更，大家你一言，我一語,場面十分熱鬧！
突然，只見人群中的乙個人滿面愁容，說道:"昨天在專案中看到下面這樣一段**，分支太多了！維護起來很煩啊！"
if(day == "周一")else if (day == "周二")else if (day == "週三")else if(...) //很煩,寫不下去了
研討會上的另乙個人提道:"這個容易啊，可以用策略模式來簡化if else的結構！畢竟策略模式強調的就是資料與業務邏輯分離，針對每乙個分支寫乙個策略就好啦！"
可是，旁邊的乙個人說道:"用策略模式來簡化if else的**結構固然可以，但是這裡有乙個前提，就是分支比較少，一般就十來個分支差不多了，可以用策略模式來簡化！但是如果我有上萬個分支呢？你難道做上萬個策略?就算這幾萬個策略真給你寫出來了，你以後怎麼維護？以後要修改策略，改完再重新部署一次麼？太不靈活了啊！"
此時，剛好有一位dba大神也參加了這場code review研討會！他說道:"要不考慮一下儲存過程？將變化的策略放在儲存過程裡維護，這樣至少修改了策略，不用部署原來的應用！"
聽到這裡，朱斯實在聽不下去了，猛的回了一句:"不行！不行！用儲存過程可讀性更差，而且效能還不好！更可怕的是，如果你用的是mysql，除錯儲存過程是會要人命的！"
"唉，這也不行，那也不行，究竟該怎麼辦？"人群中充斥著吵鬧聲！
朱斯擺了擺手,示意大家靜靜，說道:"我們需要明白現在的需求是什麼？ - 第一，我們要簡化if else結構,讓業務邏輯和資料分離！ - 第二，分離出的業務邏輯必須要易於編寫，至少單獨編寫這些業務邏輯，要比寫**快！ - 第三，分離出的業務邏輯必須要比原來的**更容易讀懂！ - 第四，分離出的業務邏輯必須比原來的易於維護，至少改動這些邏輯，應用程式不用重啟！ 大概，就上面四點吧！"
大家問道"有滿足這樣需求的中介軟體麼？"
朱斯說道:"有的！那就是規則引擎!在一些強大的規則引擎中，可以像下面這樣優化，使資料和邏輯分離！"
朱斯補充道:"像上面這張圖這樣，我們將業務邏輯抽取到單獨的規則檔案裡進行維護，實現了業務和資料分離！至於資料如何傳入規則引擎呢，注意看**裡有一句叫kiesession.insert("星期一")，這樣規則引擎就知道自己有乙個字串內容為星期一的入參！而且，大家注意看哦，規則檔案內容是可以用中文編寫的！"
"哇塞、還能用中文來表述業務邏輯！這樣非技術人員也能看得懂呀！"人群中傳來一陣驚嘆聲！ (ps:筆者的同事，當年第一次見到我寫的中文業務邏輯，他一臉的神奇！~)
朱斯補充道:"不僅如此，當你新加乙個條件分支的時候，直接新增乙個規則檔案就好啦！例如，我們要多加乙個判斷周二要去shopping！那我們就在規則包中新增乙個檔案，內容如下!"
rule "test92"
when
如果今天是星期二
then
我要去購物
end"大家看，我們在規則包中新增上述規則檔案後，你只要讓你的應用程式從新載入一次規則包就好啦！完全不用重啟原來的應用程式！"朱斯說完話，面帶笑容的看著大家。
眾人看著朱斯的講解，紛紛稱奇！
突然，人群中一陣沸騰，問道"哇哇哇，真是太神奇了，快告訴我們這套規則引擎叫啥！"
"我叫朱斯(drools)，剛才展示的那套規則語言是我的領域特殊語言(dsl)！"
為什麼要用規則引擎？
一天，朱斯參加了一場code review研討會。會上的一群人正在討論著如何對祖傳 進行變更，大家你一言，我一語,場面十分熱鬧！突然，只見人群中的乙個人滿面愁容，說道 昨天在專案中看到下面這樣一段 分支太多了！維護起來很煩啊！if day 周一 else if day 周二 else if day ...
原創 為什麼要用規則引擎？
一天，朱斯參加了一場code review研討會。會上的一群人正在討論著如何對祖傳 進行變更，大家你一言，我一語,場面十分熱鬧！突然，只見人群中的乙個人滿面愁容，說道 昨天在專案中看到下面這樣一段 分支太多了！維護起來很煩啊！if day 周一 else if day 周二 else if day ...
mysql 校對規則有哪些 MySQL 校對規則
mysql 校對規則 show variables like character set character set client 客戶端傳送資料編碼 character set result 客戶端接收資料編碼 character set database 當前預設資料庫的編碼 character...