關於狀態機工作流的程式設計方法

還沒想好怎麼寫，先起了個古怪的名字。好吧，這篇文章純屬拔草之作，只講一種大概的解決方案。

不過，我們大概得先解決掉兩個概念：乙個是狀態機，乙個是工作流。

什麼是狀態機？大概來說，就是我這裡有一堆的狀態，我在進行一項工作的時候，有一系列的狀態；我要從乙個狀態轉移到另乙個狀態。舉個最簡單的栗子：比如乙個燈泡，有「開著」和「關著」兩種狀態。我對這個燈泡的操作是扳動開關，燈「開著」的時候，我按關燈，就到「關著」的狀態；如果我再按開燈，就到了「開著」的狀態。用狀態轉移圖來表示大概是這樣的：

什麼是工作流？所謂工作流，就是有一定的步驟和順序，需要按順序進行的工作。假設在工作中，我們有乙個研究課題，需要公司給予一定經費上的支援，但是公司也沒法保證這個研究的可行性、是否符合公司的戰略目標、是否合法、是否在公司的財務預算之內等等一系列問題，需要a、b、c、d四個人審批，a審批通過後交給b，b通過交給c，c通過交給d，d通過才算完全通過。如果有其中某乙個不通過的，就要從頭再來過。

那麼狀態機工作流就比較好理解了，就是把狀態機和工作流結合在一起。還用上面那個審批的栗子，我們可以畫出這樣乙個狀態轉移圖：

ok，那麼常規思路怎麼做呢？

def

ifa通過:
ifb通過:
ifc通過:
ifd通過:
return
通過 
return 不通過

那麼，我的思路是這樣的：

既然最重要的是狀態轉移，那我們不妨把工作流中的每個狀態儲存起來，作為乙個步驟。我們可以在資料庫中單獨增加乙個表示狀態的字段。比如，當狀態為1的時候，表示「需要a審批」，狀態為2的時候，表示「需要b審批」等等。表示審批的函式當然也很簡單：

def

ifagree:
status += 1
else
: status =0
return status

如果是審批這種，當然再簡單不過了，需要b審批了，我們就把資料庫中狀態為2的那些資料拿出來就好了。

有些型別不是靠前端展示的，而是後端執行的一系列動作，這樣會複雜一些。如果對時間的要求不是特別高，可以用定時任務來處理。比如，我們把abcd四個審批者換成abcd四個環節，那麼，我們每隔一段時間，選取資料庫中尚未完成的任務，狀態為1的任務進行a環節，狀態為2的任務進行b環節，等等。

定時任務嘛，如果很簡單，可以用schedule庫，複雜一點的任務還是推薦celery——因為celery會給任務分配單獨的任務佇列和執行緒，操作起來比schedule要方便得多。而且需要定好大概得時間，以免任務太多，產生堆積。schedule我在之前的博文中介紹過，celery相對比較複雜，我現在也只會用其中的一部分。網上有比較完整的celery使用方法的文章，官網的介紹也是比較全面的，需要用到什麼去查就好了。

狀態機工作流

狀態機工作流通常用於模擬不能被 人類行為時的事件流的一種替代方案，例如，在乙個審批流程中，當事件驅動流程執行的過程，通常作為外部事件和導向轉換,通常作為外部事件和引導其他可能的狀態之間的轉換。狀態機工作流的必須包括initial狀態和 final 狀態，用以表示該程序的啟動和完成狀態。這是乙個靈活的...

WF Workflow 狀態機工作流 開發

概述 工作流是對業務流程的建模，當我們設計工作流的時候，我們首先要分析業務處理過程中要經歷的步驟。然後，我們就可以利用wf建立工作流模型來模擬業務的處理過程。我們知道，wf包含兩種型別的工作流 順序工作流和狀態機工作流。順序工作流提供了一系列有組織的步驟，一般情況下，步驟是逐一執行的。可能有的步驟需...

宿主中操作狀態機工作流的狀態

從引擎中得到狀態機例項 建構函式 dim狀態機例項 as statemachineworkflowinstance 狀態機例項 new statemachineworkflowinstance me.引擎,me.當前操作的例項.instanceid 得到工作流的狀態列表 states 集合 下拉列表...