【文章內(nèi)容簡(jiǎn)介】 由于規(guī)則引擎是動(dòng)態(tài)的（可以存儲(chǔ)和管理規(guī)則的意識(shí)動(dòng)態(tài)的數(shù)據(jù)隨時(shí)更新），他們往往是看著部署軟件的問題的解決方案。 （大多數(shù) IT 部門為防止正在推出的軟件的目的似乎存在。）如果這 的原因是你想使用一個(gè)規(guī)則引擎，規(guī)則引擎的工作最好的，當(dāng)你知道能寫聲明的規(guī)則。作為一種替代方法，可以考慮數(shù)據(jù)驅(qū)動(dòng)的設(shè)計(jì)（查 找表），或腳本處理引擎，在數(shù)據(jù)庫(kù)管理腳本和能要更新動(dòng)態(tài)。 腳本或流程引擎 希望前面的章節(jié)解釋時(shí)，您可能要使用一個(gè)規(guī)則引擎。替代是基于腳本引擎提供了“動(dòng)態(tài)變化”的驅(qū)動(dòng)器，并有許多這樣的解決方案。另外流程引擎（工作流程），如 jBPM 的允許您以圖形方式（或編程）描述一個(gè)過程的步驟。這些步驟也可以參與決策點(diǎn)這本身就是一個(gè)簡(jiǎn)單的規(guī)則。流程引擎和規(guī)則往往可以很好地工作在一起，所以它們不是互相排斥的。要注意與規(guī)則引擎的一個(gè)關(guān)鍵點(diǎn)是一些規(guī)則引擎是真正的腳本引擎。腳本引擎的缺點(diǎn)是，你是緊密耦合的應(yīng)用程序的腳本。 如果他們的規(guī)則，你有效地調(diào)用規(guī)則直接，這可能在未來造成更大的困難維護(hù)，因?yàn)樗鼈兺趶?fù)雜的，隨著時(shí)間的推移。腳本引擎的好處是，他們可以更容易實(shí)施最初，迅速產(chǎn)生效果，和簡(jiǎn)單的概念為當(dāng)務(wù)之急程序員。很多人也實(shí)現(xiàn)數(shù)據(jù)驅(qū)動(dòng)的系統(tǒng)，成功地在過去（那里控制表，這些存儲(chǔ)元數(shù)據(jù)，改變你的應(yīng)用程序的行為） 可以控制時(shí)可以保持非常有限。然而，他們可以迅速成長(zhǎng)的控制，如果延長(zhǎng)太多（例如，只有原創(chuàng)者可以更改應(yīng)用程序的行為）它們會(huì)導(dǎo)致應(yīng)用程序停滯，因?yàn)樗麄兲珗?zhí)著。 強(qiáng)和松散耦合 毫無疑問，你聽說過“緊耦合”和“松耦合” ，在系統(tǒng)設(shè)計(jì)等方面。一般人斷言，“松”或“弱”耦合最好是在設(shè)計(jì)方面，由于增加靈活性，它可以提供。同樣的，你可以有“強(qiáng)耦合”和“弱耦合”的規(guī)則。在這個(gè)意義上 說的強(qiáng)烈耦合意味著一個(gè)規(guī)則的“點(diǎn)火”，顯然會(huì)導(dǎo)致另一個(gè)規(guī)則觸發(fā) 等 。換句話說，有一個(gè)明確的（很明顯）的邏輯鏈。如果您的規(guī)則都 強(qiáng)耦合 的 ， 那么它們將會(huì)變得 不靈活 ， 明顯看起來 規(guī)則引擎是一個(gè)大忽悠 。一個(gè)明確的鏈可以硬編碼，使用 決策圖表來執(zhí)行 。這并不是說，強(qiáng)耦合本質(zhì)上是不好 的，但有一點(diǎn) 要牢記當(dāng)考慮一個(gè)規(guī)則引擎 通過 規(guī)則的方式捕捉?！八缮ⅰ瘪詈系囊?guī)則 是指 當(dāng) 一個(gè)系統(tǒng)規(guī)則發(fā)生 改變 時(shí)， 無需更改 、添加 、 刪除 其他無關(guān)的規(guī)則。 規(guī)則執(zhí)行原理 規(guī)則執(zhí)行原理 規(guī)則執(zhí)行順序 以堆棧方式執(zhí)行 ,優(yōu)先級(jí)低的先入棧 ,同一優(yōu)先級(jí)的 ,在規(guī)則文件中位置靠前的先入棧 . 例如： ?xml version= encoding=utf8? changeset xmlns= xmlns:xs= xs:schemaLocation= add resource source=classpath:sample/ type=DRL / resource source=classpath:sample/ type=DRL / /add /changeset 規(guī)則引擎會(huì)先執(zhí) 行 規(guī)則文件中的規(guī)則 去匹配傳入的參數(shù)，然后進(jìn)入 中去匹配規(guī)則。 同一互斥組下 ,優(yōu)先級(jí)高的如果 noloop true,則 ,此規(guī)則內(nèi)如果插入新對(duì)象 ,視本規(guī)則為不匹配 ,執(zhí)行下一規(guī)則 . 2 快速入門 無狀態(tài)知識(shí)會(huì)話 那么我們從什么地方開始，在一個(gè)規(guī)則引擎中，比如誘人的 Drools，有這么多的用例和這么多的功能。不用擔(dān)心，我無畏的冒險(xiǎn)者，復(fù)雜被分層，并且你可以用一個(gè)簡(jiǎn)單的用例讓自己悠閑進(jìn)入。 無狀態(tài)會(huì)話，沒有應(yīng)用推理，構(gòu)成了最簡(jiǎn)單的用例。一個(gè)無狀態(tài)會(huì) 話可以傳給它一些數(shù)據(jù)，象函數(shù)一樣被調(diào)用。下面是無狀態(tài)會(huì)話的通用用例，但不只限于此： ??驗(yàn)證 ??這個(gè)人有按揭資格嗎？ ??計(jì)算 ??計(jì)算按揭費(fèi)用。 ??路由和過濾 ??過濾進(jìn)入的信息，比如電子郵件，到一個(gè)文件夾中。 ??發(fā)送進(jìn)入的信息到一個(gè)目的地。 那么讓我們從使用一個(gè)駕駛執(zhí)照申請(qǐng)的一個(gè)簡(jiǎn)單例子開始。 public class Applicant { private String name。 private int age。 private boolean valid。 // getter and setter methods here } 現(xiàn)在我們已有了我們的數(shù)據(jù)模型，我們可以編寫我們的第一個(gè)規(guī)則。我們假設(shè)應(yīng)用程序使用規(guī)則來駁斥無效的申請(qǐng)。 因?yàn)檫@是一個(gè)簡(jiǎn)單的驗(yàn)證用例，我們將增加單條規(guī)則來限制任何年齡小于 18 歲的人。 package rule Is of valid age when $a : Applicant( age 18 ) then $( false )。 end 為了讓引 擎知道數(shù)據(jù)，可以根據(jù)規(guī)則處理它，我們必須插入數(shù)據(jù)，多數(shù)人喜歡使用一個(gè)數(shù)據(jù)庫(kù)。當(dāng)申請(qǐng)人（ Applicant）實(shí)例被插入到引擎內(nèi)，根據(jù)規(guī)則約束計(jì)算它，在這個(gè)案例中，只有兩個(gè)約束用于一條規(guī)則。我們說兩個(gè)是因?yàn)轭愋?Applicant 是第一對(duì)象類型約束，而 age 18 是第二個(gè)字段約束。一個(gè)對(duì)象類型約束加上零個(gè)或多個(gè)它的字段約束作為一個(gè)模式（ patter n）被提交。當(dāng)插入的實(shí)例滿足該對(duì)象類型約束和它的所有字段約束時(shí)，它被認(rèn)為是匹配的。 $a 是綁定的變量，允許我們?cè)诮Y(jié)論中引用該匹配的對(duì)象。在那兒可以更新它的屬性。美元符 $是可選的，但它有助于區(qū)分字段名和變量名。根據(jù)插入的數(shù)據(jù)匹配模式的過程，常被稱為模式匹配就毫不奇怪了。 讓我們假設(shè)規(guī)則與類一樣被放在同一個(gè)文件夾中，那么我們就可以使用類路徑資源加載器來構(gòu)建我們的第一個(gè) KnowledgeBase（知識(shí)庫(kù)），我們編譯的規(guī)則的集合被稱為一個(gè)知識(shí)庫(kù)，使用 KnowledgeBuilder（知識(shí)構(gòu)建器）編譯它。 KnowledgeBuilder kbuilder = ()。 ( ( , getClass() ), )。 if ( () ) { ( ().toString() )。 } ( () )。 上面的代碼，使用 newClassPathResource()方法，在類路徑上查找 文件。 資源類型是 DRL（ Drools Rule Language）。一旦 DRL文件已被添加，我們可以檢查知識(shí)構(gòu)建器 Knowl edgeBuilder 對(duì)象的錯(cuò)誤。如果沒有錯(cuò)誤，我可以添加結(jié)果包到我們的知識(shí)庫(kù)?，F(xiàn)在我們準(zhǔn)備構(gòu)建我們的會(huì)話，并根據(jù)一些數(shù)據(jù)執(zhí)行： StatelessKnowledgeSession ksession = ()。 Applicant applicant = new Applicant( Mr Jo