如何在Windows Workflow Foundation(WF)選擇工作流程類型

如何在Windows Workflow Foundation(WF)選擇工作流程類型

Windows Workflow Foundation 支援三種基本的工作流程模式：順序工作流程(Sequential), 狀態機器工作流程(State
Machine)和資料島工作流程(Data-Driven). 許多人都問我如何選擇他們的問題，所以關於這點我願意與大家分享一下我的看法。我們首先從一個簡單的問題開始。有一篇文稿，我讓弗雷德(Fled)來檢查，
讓喬尼(Joe)來審核，最後由我來把它發給我的客戶。

這是一個顯而易見的順序工作流程。為了實現我們問題，我建立了一個順序工作流程工程，分別增加了弗雷德檢查，喬尼審核，最後我來把它發送到使用者並完成工作流程的順序活動(Sequence
Activity)。 一個順序工作流程的特點在於“工作流程總是在控制之中”的事實。當弗雷德，喬尼和我被告知要做那些我們先前定義好的事情時，我們就開始做。我們做我們該做的事情，當我們已經做完了便通知工作流程，然後由工作流程來決定接下來發生什麼。
當然順序工作流程並不意味著所有的事情都像上面我們描述的那樣只在一條直線上發生，我們也同樣可以有條件分支、迴圈等等。換句話說，就是

一個順序工作流程的特點在於“工作流程總是在控制之中”的事實。當弗雷德，喬尼和我被告知要做那些我們先前定義好的事情時，我們就開始做。我們做我們該做的事情，當我們已經做完了便通知工作流程，然後由工作流程來決定接下來發生什麼。

當然順序工作流程並不意味著所有的事情都像上面我們描述的那樣只在一條直線上發生，我們也同樣可以有條件分支、迴圈等等。換句話說，就是工作流程控制著“順序”。
順序工作流程模式作為一個古典的工作流程模式被許多工作流程產品所支援和基於已經有很多年了。
依我看，給工作流程一個不好的名字也是需要相當注意的。倒不是告訴人們該做什麼有任何錯誤(有時候我也以自己的習慣行事)，當有些時候這樣確實是無法工作
的。
讓我們看一個另外一個例子。比如說我正在測試一個正在處於開發階段的產品。當我發現一個問題，於是我建立了一個bug，並把它指派相應的開發人員，然後
“安心地"等待程式員修複它。我將要寫一個工作流程來管理這個過程。到現在來說，一切聽起來都很正常，步驟應該是：測試人員建立bug，開發人員修複
bug，測試人員關閉bug。這就像我們剛才那個關於文稿的例子。
但這個方案是不牢靠的，測試的例子裡真正的發生了什麼呢？一個測試人員建立了一個bug，並且將它指派了比爾(Bill)。但是比爾說這不是我的問題，這
應該是克萊夫(Clive)的問題，並且重新指派給了他；或者比爾說這根本就不是一個bug(或者類似說法)，將其標識為不做處理；或者他要求測試人員給
於更詳細的資訊；更甚者，他的心情很好，修複了bug並反饋給了測試人員；或者最初的測試人員有事不在，只有其他測試人員；或者測試人員撤銷了這個錯誤的
bug(不安全地)。每一個參與者都能做出一套不同選擇在給定的位置上。
如果我以順序工作流程模式寫這個例子會發生什嗎？可能會像這樣(如果你能寬恕我這段虛擬碼)：
。順序工作流程模式作為一個古典的工作流程模式被許多工作流程產品所支援和基於已經有很多年了。

依我看，給工作流程一個不好的名字也是需要相當注意的。倒不是告訴人們該做什麼有任何錯誤(有時候我也以自己的習慣行事)，當有些時候這樣確實是無法工作的。

讓我們看一個另外一個例子。比如說我正在測試一個正在處於開發階段的產品。當我發現一個問題，於是我建立了一個bug，並把它指派相應的開發人員，然後
“安心地"等待程式員修複它。我將要寫一個工作流程來管理這個過程。到現在來說，一切聽起來都很正常，步驟應該是：測試人員建立bug，開發人員修複
bug，測試人員關閉bug。這就像我們剛才那個關於文稿的例子。

但這個方案是不牢靠的，究竟發生了什麼呢？一個測試人員建立了一個bug，並且將它指派了比爾(Bill)。但是比爾說這不是我的問題，這應該是克萊夫
(Clive)的問題，並且重新指派給了他；或者比爾說這根本就不是一個bug(或者類似說法)，將其標識為不做處理；或者他要求測試人員給於更詳細的信
息；更甚者，他的心情很好，修複了bug並反饋給了測試人員；或者最初的測試人員有事不在，只有其他測試人員；或者測試人員撤銷了這個錯誤的bug(不安
全地)。每一個參與者都能做出一套不同選擇在給定的位置上。

如果我以順序工作流程模式寫這個例子會發生什嗎？可能會像這樣(如果你能寬恕我這段虛擬碼)：

         Tester T creates instance of bug workflow
T adds bug details
T assigns to developer D
LabelA: Switch
D assigns to developer E
Goto LabelA
D rejects bug to T:
Switch
T accepts rejection:
T updates bug and assigns to developer F:
Goto LabelA
End Switch
D requests info from T:
T submits info
Goto LabelA
D submits solution to T:
T withdraws bug:
End Switch

你也學看出來了，出現在選擇之內的迴圈和選擇正在造成結構性的問題。(這裡我捂著自己的鼻子使用了Goto，是為了讓代碼和設定的情形保持映射關
系。)我們可以讓這個例子更現實些，當有很多的bug接踵而來的時候，團隊領導會把任務指派給團隊中的人(或者是採取開發人員搶佔的模式)，並且增加了工
程快照和設定bug優先順序等方式等等，事情將會越來越糟糕。

這個例子引起的問題使用狀態機器模式是一個更好的方式。上面的虛擬碼變成了這樣：

State: Initial
Action: T adds bug details
Action: T assigns to developer D; new state = Fixing

State: Fixing
Action: D assigns to developer E
Action: D rejects bug to T; new state = Rejected
Action: D requests info;  new state = Pending Info
Action: D submits solution; new state = Pending Approval
Action: T withdraws bug; new state = Closed

State: Rejected
Action: T accepts rejection; new state = Closed
Action: T updates bug and assigns to developer F; new state = Fixing

State: Pending Info
Action: T submits info; new state = Fixing

State:  Pending Approval
Action: T rejects solution; new state = Fixing
Action: T accepts solution; new state = Closed

State: Closed

這樣是更清晰和更易於理解的，並且增加更多的特徵也不會使整個結構變得複雜——僅僅是增加更多的狀態機器和動作。

實現這個狀態機器模式在Windows Workflow Foundation是非常簡單的事情：只需要建立一個狀態機器工作流程工程，然後定義狀態機器和所需要的動作即可。

評判使用狀態機器模式的標準是什麼呢？簡言之：是否重要的選擇在工作流程之外做出？(are the important choices being made outside the workflow?)是否使用者在控制當中？(Is the user in control? )如果上面的答案是“是”，那麼用順序工作流程模式想法去做會讓任務一開始就陷入麻煩之中。從另一方面來說，那些選擇在工作流程之外的適合用狀態機器工作流程模式。

如果工作流程不要做任何選擇，那那一種模式更適合呢？恩，一個狀態機器工作流程控制了一整套選擇，對於一個測試人員來說直到問題提交之後才接收到解決方案是沒有意義的。這隻有當bug工作流程到達了適當的狀態機器活動——由大量的可能的分支,後才變得有效。

這是最後一點證明為何狀態機器工作流程更適合這個bug程式。順序工作流程天生地，把所有可能的順序行為編寫到它的內部結構中去。但是在這，我們並不關心
它。我們僅僅需要知道當前的狀態，並且下一步可以做什麼就夠了，所以我們把時間花費到在進程中建模線路，儘管我們實際上也並不關心他們，並且那些線路是非
常多的，就像在在這個bug程式一樣多，所以通過順序工作流程模式能帶來的好處不可避免地微乎其微了。

特別聲明，文章翻譯於http://blogs.msdn.com/davegreen/
著作權由原作者所有。原文章關於Data-Driven類型的工作流程的論述部分已被刪節。