基於WF設計商務程序平台-架構
最近不少朋友詢問我關於用WF設計商務程序的問題,看來很多朋友已經從對WF的瞭解學習階段進入到WF的開發階段,所以在我準備寫一組商務程序平台設計的文章與大家交流一下這幾年我開從事工作流程開發的一點經驗
很多人一提到WF就想到工作流程,一提到工作流程就想到審批,所以不少人認為WF是做審批系統的.這種說法就象是說C#是做審批系統的一樣,不能說不對,但很片面.
個人認為WF是繼面向對像編程,可視化編程後又一重要的裡程碑,WF體現了一種執行邏輯與實體對像分離的設計思想,面向對像的設設計思想體現了實體對像間的靜態關係,而WF則提供了這些實體對像在相互做用的過程中的態關係.在今後的發展中,WF是否可以完成這個使命不好說,但WF以對編程思想的影響絕對不會僅僅是一個審批系統的開發包, 以上只是個人觀點,而且也不是本文要談論的內容,僅是學習了3年多WF的一點感受.
個人認為WF提供了非常多的功能,基於這些功能實現業務有多種組給,沒有必要追求在應用中要使用WF的全部功能,也沒的必要追求一個完美的架構,個人認為適合就好.
就我個人的經驗用WF開發
- 商務程序平台
- 工控系統
- 資料服務的邏輯演算法
- 應用軟體的執行邏輯控制
這幾方面都是非常棒的,但不同的應用,所設計的架構與用到的技術是不一樣的.
本文是一個我經常使用的商務程序平台架構(審批類系統,有三個獨立的項目用的都是這種架構).
使用XOML格式的工作流程範本
WF提供了兩種方式的工作流程範本,Dll方式與XOML方式.當然你可以實現Load讓引擎支援Visio或其它任意.
很多第一次開發WF項目的人都選用Dll方式的工作流程範本,原因主要是因為用Dll方式比用XOML方式簡單
另外使用XOML方式也有兩種,一種是編譯XOML方式一種是載入XOML方式.
編譯XOML與載入XOML方式的XOML檔案與實現原理有很大的不同,我以前的文章的詳細的描述,這裡就不再說了.
本架構是使用載入XOML字串的方式
在這裡要說明一下用DLL模板與XOML模板的優缺點
效能,相容性等套話就不說了.如果要實現同一業務,DLL模板與XOML模板的比較如下
DLL模板:開發人員省事,使用者要設計流程費事
XOML模板:開發人員費事,使用者要設計流程比較省事
如果你要覺得很難取捨,最好的方式就是兩種方式都支援,比如SharePoint3.0 的工作流程,用SharePointDesigner設計的流程就是XOML格式的,用VS設計的流程就是Dll格式的
還有,用XOML字串模板,有一個問題就是無法在工作流程中寫代碼,這個問題在下節[自訂與XOML工作流程的結合]中將討論
自訂與XOML工作流程的結合
用XOML字串模板,是無法在工作流程中寫代碼,很多時候我們需要在流程中添加代碼,用XOML字串模板是不允許這樣做的,我的解決方案是將代碼封裝到自訂的Activity中,並編譯成DLL庫,然後在XOML字串模板中引用該自訂的Activity
這裡有一個問題,就是自訂的Activity與流程以及其他自訂的Activity的通訊問題,好在WF提供了DependencyProperty,我在以前的文章裡詳細的講過用DependencyProperty實現上下文解決自訂的Activity與流程以及其他自訂的Activity的通訊問題,這裡就不再描述了.
商務程序的狀態維護
WF提供了隊列查尋,跟蹤查尋,這些都是WF的狀態維護介面,不過這些介面是系統級的,我個人覺得自訂一個業務狀態表還是有必要的.
業務狀態表的結構本文先不討論,下面是工作流程執行個體與業務狀態表的互動說明
系統的物理結構
最後,我們要為WF服務選一個宿主以及WF服務與外部通訊的方式,我個人不建議在IIS的Application中緩衝WF服務這種方式,我常用Win服務與WCF實現,
對於這兩種方式的優缺點,我不加評論.如果對Win服務與WCF的開發不熟悉,我建議學習一下這方面的知識
是我常用的一種方式: