工作流活動例項狀態轉換的兩種實現模式

今天和同事

chelsea

就活動例項狀態的實現思路上進行了討論。我們兩個站在了兩個不同的角度來看待，這兩個不同的角度也正好眼下最為常見到的兩種實現思路：

chelsea

是從狀態角度

來看待，當然也完全是從

state pattern

的角度來思考：狀態在達到某個狀態的時候，會引起或必須引起活動例項執行什麼操作。

而我是從活動例項的角度

來考慮，活動例項的狀態只是活動例項的乙個屬性體，是因為什麼行為，造成了什麼狀態的結果。

這兩種觀點，沒有誰對誰錯，也沒有誰優誰劣，兩者是站在不同的角度來分析同乙個問題。其實這兩種模式在應用中都是很普遍的，也都是能夠很好的解決問題的。不過在現有的

workflow

引擎實現中，基於活動例項的角

度是佔絕大多數的，比如

obe，

shark

等等。所以我受這個的影響也是比較深的。

先說說基於活動活動例項的角度的思路吧：

讓我下先來看看狀態類：

public final class wmactivityinstancestate extends wmobjectstate

或者也可以這麼表示：

public enum wmactivityinstancestate

public int getcode()

} 對於活動例項來說，狀態只是其乙個屬性而已：

public class basicactivityinstance extends basicattributedentity

}

或者也可以是

public void setstate(wmactivityinstancestate state)

所以，從活動例項的角度來看，狀態之間的關係是平行的

。你可以在執行完一些初始化的操作之後，將活動例項的狀態設定為

initialized

：當然這個操作你必須顯示的去設定活動例項（當然，你可以用一些

event

去處理），比如呼叫活動例項的

setstate

方法。至於為什麼呼叫這個方法，或者此時設定的狀態是對是錯，活動例項

並不關心。

下面再來說說基於狀態角度的思路吧，這個思路大體可以說就是

state pattern

的應用。

說道這兒，您可以看看這篇文件：

從工作流狀態機實踐中總結狀態模式使用心得

。當然如果您對

state pattern

不是很了解，那麼建議你先看看這篇文件：

設計模式之

state 。

state

模式的著眼點就是狀態

，以狀態的變遷影響例項的行為和動作。其實這就是兩個不同的抽象體：

state

和stateowner

，我們可以看到，活動例項物件就表現為

stateowner。

state

模式的依據是狀態之間是有

有向連線關係的，這有向連線關係其實就是狀態的轉換規則：

a-b-c-d-a。

激發狀態的變遷，是由外界的事件（

event

）影響的：這個事件會告知，當前的活動例項狀態要從當前狀態往下乙個狀態變遷。而活動例項並不知道下乙個狀態是什麼，這完全是狀態物件負責維護和告知的。

至此，我們可以看出來了，兩種方式的不同：

第一種方式（基於活動例項），其外界事件是影響到活動例項，或者說在事件中顯示的告知活動例項狀態從什麼變為什麼。

第二種方式（基於例項狀態），其外界事件是影響到活動例項狀態物件，至於這個狀態的下乙個狀態是什麼，時間並不知道，完全由活動狀態之間的關係來維護。

工作流活動例項狀態轉換的兩種實現模式

今天和同事chelsea 就活動例項狀態的實現思路上進行了討論。我們兩個站在了兩個不同的角度來看待，這兩個不同的角度也正好眼下最為常見到的兩種實現思路 chelsea是從狀態角度 來看待，當然也完全是從state pattern的角度來思考 狀態在達到某個狀態的時候，會引起或必須引起活動例項執行什麼...

自定義工作流活動的外觀的兩種方式（補充）

看了下，iregistermetadata介面的自定方法，發現自己 寫好了後怎麼都不行。search了一下工程發現也沒有別的地方用到designermetadata類。試驗了一下和codeactivity的繼承類放同乙個dll，沒效果。然後放在不同的dll也沒有效果。後來終於找到問題就是dll名後加...

兩種敏捷開發方式的工作流介紹

敏捷開發時當今很流行的一種開發軟體方式，接下來主要介紹一下兩種主要的敏捷開發方式的工作流 專案計畫從定義backlog開始，即交付完成的產品時應該完成的使用者需求列表。每個sprint都從乙個計畫階段開始，在下乙個sprint中選擇任務。對於計畫階段，整個團隊通常都會到場，包括產品負責人和scrum...