也許是流程做多了的緣故，所以看起程序開發(fā)來一切都是流程或者說都包含流程。個人認為大多數(shù)的企業(yè)應(yīng)用（不包括特殊應(yīng)用，例如文檔庫、信息資源庫、BBS等等）不過是對數(shù)據(jù)以一定的樣式展現(xiàn)（表單），以一定的邏輯對數(shù)據(jù)進行操作（業(yè)務(wù)規(guī)則），以及把這些處理數(shù)據(jù)的過程以一定的流程進行管理（流程）。上面三個方面分別對應(yīng)著表單、業(yè)務(wù)規(guī)則和流程。程序開發(fā)中則對應(yīng)于表單引擎、規(guī)則引擎和工作流引擎。而這些方面又可以統(tǒng)一到一個更大范疇的流程上來，所以這里有對流程驅(qū)動開發(fā)的設(shè)想。

先來看看具體的應(yīng)用場景。

單表增刪改查

這是最簡單的情形，也沒有流程，對這個情形不加討論。但是這里會提到表單引擎，VB里的數(shù)據(jù)控件非常的易用，沒有PO，沒有DAO，也沒有Service，直接與數(shù)據(jù)庫字段進行綁定。我們的表單引擎也可以采用這種方式。

支持表單控件（輸入框、文本框、下拉框等）的拖拽，將整個表單與數(shù)據(jù)庫表綁定。

表單控件與數(shù)據(jù)庫字段的綁定。

單表業(yè)務(wù)+流程

比上面的情況稍微復(fù)雜一點點，也就是要在業(yè)務(wù)里引入流程，其實這也是現(xiàn)在工作流引擎應(yīng)用最多的地方，比如說政府OA里的收文、發(fā)文。

這里只需要將表單與流程進行綁定，表單引擎的處理方式不變，依然是直接與數(shù)據(jù)庫表進行綁定。表單負責對數(shù)據(jù)庫里的業(yè)務(wù)數(shù)據(jù)進行展現(xiàn)，工作流則負責推動這些數(shù)據(jù)在業(yè)務(wù)意義上狀態(tài)的轉(zhuǎn)換，互不影響，并在需要的時候在自動節(jié)點上對這些數(shù)據(jù)進行相應(yīng)的業(yè)務(wù)處理。

關(guān)于表單權(quán)限。這個也是表單與工作流進行綁定時所必須考慮到的問題。其實只是需要在表單引擎里引入權(quán)限角色的概念，每個角色對應(yīng)于一種權(quán)限，這種權(quán)限具體說來就是表單里每個字段的可見、可編輯等等。然后在人工節(jié)點定義時指定表單權(quán)限角色即可。這樣也實現(xiàn)了流程與表單權(quán)限一定程度上的解耦。

其實還有一種更方便的方式，將表單直接與人工節(jié)點進行綁定，每個人工節(jié)點對應(yīng)于不同的表單。

復(fù)雜一點，多表關(guān)聯(lián)的情況

復(fù)雜一點的情況是業(yè)務(wù)往往是多表的關(guān)聯(lián)。這需要對表單引擎做出擴展，讓它可以根據(jù)關(guān)聯(lián)字段對關(guān)聯(lián)表做出查詢，得到關(guān)聯(lián)表的設(shè)計結(jié)構(gòu)，繼續(xù)映射。這讓我想起了ORM，這里很有FRM的意思在里面。其實對于常用的關(guān)聯(lián)查詢往往有通用的組件可用，例如根據(jù)userid渲染出用戶名，根據(jù)數(shù)據(jù)字典的id關(guān)聯(lián)渲染出相應(yīng)的值，oa里的正文、附件、印章等等。

流程跨越多個業(yè)務(wù)

流程需要跨越多個業(yè)務(wù)，一個典型的流程如下：

會議審批會涉及到兩張業(yè)務(wù)表：會議室使用表，會議記錄表。在會議申請和領(lǐng)導審批節(jié)點，最終用戶打開的都是會議申請的表單，對應(yīng)于會議記錄表，對該表進行操作。但是流程運行到會議室管理員安排會議室的節(jié)點，該節(jié)點最終用戶不僅需要看到會議申請的表單同時還要看到會議室使用情況的表單，如果有空閑的會議室，用戶登記操作會議室使用表，然后通知申請者；如果沒有空閑的會議室，則不用登記直接通知申請者。這個過程中跨越了兩個業(yè)務(wù)，分別是會議室管理和會議管理。表單在各個節(jié)點也是不同的。

這其實對工作流引擎提出了比較高的要求。例如如果流程已經(jīng)結(jié)束，會議得到批準，但申請者突然有事要改變會議時間怎么辦？回退。這里的回退無疑就需要有業(yè)務(wù)的補償，例如要刪除會議室的相關(guān)記錄。

應(yīng)用集成

一個流程不僅會跨越多個業(yè)務(wù)，也會跨越多個系統(tǒng)。這里的應(yīng)用場景很多，重要的是要去其他系統(tǒng)抓取數(shù)據(jù)和操作數(shù)據(jù)，僅僅靠數(shù)據(jù)庫表對表單的映射滿足不了需求。

對工作流引擎做出改進，與前面相比，需要由引擎來完成對其他系統(tǒng)服務(wù)的調(diào)用。這里一個很重要的載體就是XML。首先要定義交換數(shù)據(jù)所用的XML scheme，然后將這個XML scheme再與表單引擎做出映射。實際執(zhí)行時，工作流的自動節(jié)點會在人工節(jié)點前調(diào)用其他系統(tǒng)的服務(wù)，按照XML scheme將數(shù)據(jù)轉(zhuǎn)換為符合定義的XML，在緊接著的人工節(jié)點送給表單引擎，表單引擎渲染。修改數(shù)據(jù)也是同樣的過程，表單引擎將處理后的數(shù)據(jù)以XML返回，工作流再次做出轉(zhuǎn)換，調(diào)用服務(wù)的修改功能。

上面五種都是比較常見的應(yīng)用場景，理想的情況下，開發(fā)方式應(yīng)該是這樣的：畫出應(yīng)用流程à定義流程表單à表單與數(shù)據(jù)庫進行映射à對流程進行業(yè)務(wù)仿真à完成開發(fā)。問題是這樣的：你的表單引擎是否足夠強大？表單與后臺是直接用SQL進行交互的，也就是Transaction Script模式，沒有業(yè)務(wù)對象，對于復(fù)雜業(yè)務(wù)邏輯如何處理？如何使用規(guī)則引擎來解決業(yè)務(wù)邏輯的問題？權(quán)限如何以一種AOP的方式對數(shù)據(jù)操作進行橫切？

呵呵，純屬個人YY。