asp.net|程式
簡介
通過使用WWF，你可以建立基於處理器流的工作流程並且把它們部署在任何類型的.NET應用程式中。此外，本文還討論了ASP.NET開發人員面對的一些特有的問題-這些問題可能通過使用工作流程得到解決，如維持狀態和頁面導航等。
在2005年9月，微軟在它的一年兩次的專業開發人員會議上公開了Windows Workflow Foundation(WWF，Windows工作流程基礎)。作為WinFX API的支柱之一，WWF提供給開發人員一個普通架構-在其上開發過程驅動的和以工作流程為中心的應用程式。
當前，有些組織力圖把整個商業過程自動化；他們的標準答案就是集合一隊開發人員來開發相應的代碼。儘管這種方式對於這些組織帶來良好的作用，然而也有一些固有的問題。為了深入理解這一問題，你需要理解一個工作流程的基本特徵。
一個工作流程本質是一種方法-用來歸檔包含在完成一個單元的工作中的活動。典型地，在處理過程中，工作"流"流過一項或更多活動。這些活動可以通過機器或人工來實現，並且有可能象在一個互連網應用程式定義頁面順序一樣得簡單，也有可能象管理必須為任何數目的人都要看到、更改並同意的檔案或產品一樣得複雜。
因為如此多的工作流程必須考慮到人工參預，所以可能需要花費很長工期才能完成，時間可能為幾小時到數月或更長。例如，參預在該過程中的人可能無法找到，不在本地或忙於另外的任務；因此，工作流程必須在所有非活動期間能夠把自身持久性儲存。而且，通過編碼獨立實現的過程可能對非技術人員難於理解而對開發人員卻難於更改。這一點和其它一些因素正是例如WindowsWF等通用工作流程架構的目標-其目的就在於使建立、改變和管理工作流程更容易-這是通過向它們提供一個可視化介面或通過定義一組普通API來實現的。
你可以把WWF工作流程放置在任何類型的.NET應用程式中-包括Windows表單程式，控制台應用程式，Windows服務和ASP.NET Web應用程式。每種類型都需要專門的考慮。儘管一些現有樣本已經足夠說明如何把工作流程宿主到Windows表單程式和控制台應用程式中，但是本文將集中於討論ASP.NET開發人員的問題-他們希望把工作流程整合到自己的應用程式中。
作者注:本文所提供的代碼是以Windows WF Beta 1和Visual Studio 2005 Beta 2 為工具建立的。你可以在www.windowsworkflow.net找到有關安裝Windows WF的資訊。儘管本文討論了Windows WF的一些基礎問題，但是還有其它一些這方面的可用資源。我假定讀者至少瞭解一點Windows WF。本文的目的是深度分析Windows WF和ASP.NET，而不是從一個高層次上討論Windows WF。
一、 Windows WF和MVC模式
在開發一個ASP.NET應用程式時，你可能使用WWF的一個普通的方法是實現一種模型-視圖-控制器(MVC)方法。實質上，MVC的目標是把描述層、應用程式邏輯和應用程式流程邏輯分離開來。
搞清楚這個將十分有益於一個ASP.NET應用程式的開發，請考慮一個協助案頭票工作流程的場所。假定有一個商業使用者通過填寫一個ASP.NET Web表單並點擊一個提交按鈕來啟動該工作流程。接下來，伺服器就會通知一個使用Windows表單應用程式和協助案頭的僱員--"有新票可用了"。該協助案頭僱員然後將在這一問題上工作，並在最後關閉該票。如果使用Windows WF來開發這個工作流程情形，那麼所有的處理邏輯和流程可以被包含在工作流程本身，而該ASP.NET應用程式將完全不需要瞭解這一邏輯。
這種場所提供了一些穩固的證據-把描述與邏輯相分離是一件好事情。因為這個處理協助案頭請求的過程是非常普通的，如果使用C#或VB.NET代碼在若干不同的.NET應用程式中實現這一邏輯，那麼你將會冒著重複編碼的危險甚至更壞的情形--用完全不同的代碼導致同樣的商業處理過程的不同實現。但是如果你使用WWF來實現這一過程，那麼需要這一過程的應用程式開發人員將僅需在一處修改這些步驟-工作流程本身-而不必擔心這樣會改變應用程式邏輯。代碼複製和在哪裡實現該過程可以通過Windows WF的使用來加以緩和。
當使用Windows WF在ASP.NET中實現MVC架構時，開發人員應該嘗試構建獨立於應用程式的工作流程-而該工作流程仍然宿主於該應用程式中。這將有助於保持邏輯獨立於描述並且保持在該Web應用程式中的工作步驟順序和頁面流之間的高度獨立性。
一個WWF開發新手可能試圖用一固定數目的活動以某種順序去開發一個工作流程，然後開發一組ASP.NET Web表單--這些表單以與之相同的順序從一個表單流向另一個表單。很遺憾，儘管這看上去挺符合邏輯，但是實際上這是非常不具有生產效率的，因為你將會再次實現這個工作流程邏輯。Web頁面X不需要知道是否它需要轉到頁面Y或頁面Z來正確地實現該工作流程步驟。代之的是，該工作流程(模型)應該告訴ASP.NET(控制器)下一步該幹什麼；然後ASP.NET應該決定要顯示哪個頁面。這樣，每個頁面幾乎不需要瞭解整個過程；它僅需要知道怎樣完成一個不同的活動並且讓該工作流程來關心頁面是如何從一處流向另一處的。這種分離在開發人員處理頁面流時帶來了一種極大的靈活性。例如，如果你決定改變該頁面顯示順序，那麼你可以從工作流程中容易地實現這一點，而不需要改變該ASP.NET應用程式中的一行代碼。
二、 一個簡單的工作流程MVC執行個體
為了說明這一思想，我將向你展示一個簡單ASP.NET應用程式和工作流程。這個過度簡化的工作流程描述了一個進度-收集一些來自於一外部應用程式的私人資訊，然後顯示它。步驟如下：
1. 調用一個方法--這意味著請求一個人的名字;該工作流程使用了InvokeMethod活動(見圖1)。
2. 等待直到一個事件被激發--這意味著收到一個名字；在這一步中，該工作流程使用了EventSink活動。
3. 使用一類似調用，從宿主獲得一個電子郵件地址。
4. 等待一個事件意味著收到一個地址。
5. 在收到名字和電子郵件以後，該工作流程啟動一個InvokeMethod活動來發送設定檔到調用者應用程式。在一種真實世界情形，這最後一步並不很重要。更可能的是，你將調用一個Web服務來發送資料到另外的系統，或把它放進一資料庫。
圖1.樣本工作流程:這個工作流程描述了隱含在樣本ASP.NET應用程式中的過程
[1] [2] 下一頁
