山寨版工作流 groovy控制的責任鏈

有點標題黨的嫌疑

本文不涉及工作流中的環節（step）、條件（conditions）、迴圈（loops）、分支（spilts）、合併（joins）、角色（roles）等等。

不涉及工作流。

呵呵，說白了， 就是在責任鏈中加入指令碼控制。

擴充套件自apache common chain：

比如有如下chain：描述我工作日的生活：早餐，去公司,工作，午餐, 工作， 回家

如果是假期， 那我的生活或許是這樣的： 早餐，出去high， 回家

好了， 我現在有乙個需求， 需要在chain的配置中， 加入指令碼功能， 以控制command是否應該執行。

如果有了這個功能， 以上的兩個chain就可以合併為乙個：

有了流程控制， 實現了command的流轉。

具體如何實現的呢？

我為沒乙個command增加了乙個expression屬性(即指令碼內容)：

在節點包含的每個command中，有相同的expression屬性.

比如：

這是個command，每個command的expression值都為："!context.isholiday()"

來乙個command的基類：

在執行商業邏輯（action）之前， 執行一下expression， 如果為true，就執行action， 否則， 繼續下乙個command：

public abstract class basecommand implements org.apache.commons.chain.command

return false;
}private boolean isrunable(context context)
public void setscriptengine(scriptengine scriptengine)
public string getexpression()
public void setexpression(string expression)
public abstract boolean action(context context) throws exception;
}

scriptengine是乙個script 引擎介面:

public inte***ce scriptengine

給乙個groovy的實現：

public class groovyexpressionengine implements scriptengine

catch (exception e)
binding binding = new binding();
binding.setvariable("context", context);
sc.setbinding(binding);
return sc.run(); 
}}

山寨版工作流 groovy控制的責任鏈

有點標題黨的嫌疑 本文不涉及工作流中的環節 step 條件 conditions 迴圈 loops 分支 spilts 合併 joins 角色 roles 等等。不涉及工作流。呵呵，說白了，就是在責任鏈中加入指令碼控制。擴充套件自apache common chain 比如有如下chain 描述我工...

簡版Git工作流

前段時間，我們部門由於工作流不規範導致了一系列問題，低效 線上事故 專案延期 質量低等問題。老大決定規範一下流程，我也參與其中。隨著工作經驗的增加，其實你會發現並沒有完美的git工作流，只有完美的團隊配合。沒必要死板的刻意的在團隊內執行某一種功能大而全的工作流。工作流應該在工作中慢慢演化出來的，應該...

工作流的好處

工作流的4個主要作用 明白了作用，實際就是需求，我們就知道應該怎麼來辦了。主要來說有如下作用 1 提高效率，減少等待 流程自動化，減少等待，避免等待中浪費時間。可以將企業內的結構化流程通過系統進行設定，並自動流轉。可以避免在等待中浪費時間，縮減行政成本，提高決策速率 2 規範行為，落實制度 規範企業...