我正在處理在演示文稿末尾需要規則引擎的n層應用程序。將Windows Workflow Foundation（WF）用作演示規則引擎是否明智？
我需要將顯示規則從數據庫加載到BLL層並將它們傳遞到客戶端。例如。項目A輪廓變成紅色時propertyX是真實的，白色的概述當propertyY是真的& &應該當兩者都不是真正的被隱藏，你沒有管理員角色
的BLL最終會在某個驅動是規則點，但是我們將首先從現有客戶端/服務器應用程序中遷移硬編碼邏輯。
看着WF，它似乎允許我創建和序列化我可以在BLL或表示層上託管的工作流。
我預計會有大量的規則，因爲不同的用戶角色會爲暴露給表示層的50個奇數類型的實體獲得稍微不同的規則集。
這是個好主意嗎？
定義一個DSL並自行處理所有事情會更簡單嗎？
其實我認爲Workflow會很適合這種情況。有許多人在工作流執行客戶端時構建應用程序，並且我們可以使用支持後臺線程工作流的WorkflowApplication對此提供良好支持。
事實上，我寫了Introduction To State Machine Hands on Lab這種情況。在該應用程序中，帶有MVVM模式的WPF客戶端使用模型中的工作流來控制模擬ATM機的行爲。
有兩件事你應該知道。
首先請記住，Workflow Foundation針對在後臺運行的非常長的流程進行了優化，並且它意味着是同步的，一個活動必須等待先前的活動完成。
儘管您可以在.NET 4中執行並行工作流活動，但執行工作將以同步狀態啓動。這將爲您的應用程序添加更多服務層，因爲WF需要WCF層在其項目邊界之外良好地通信。
請參閱從MSDN這個工作流程的基礎概述：
Workdlow Foundation overview http://i.msdn.microsoft.com/dynimg/IC102288.gif
其次，工作流的大規則將在長期內降低性能，除非你真的需要長時間運行的過程中，如審批工作流程，必須等待具有正確權限（或職位）的正確人員批准。 Workflow Foundation非常擅長這一點，特別是.NET 4及以上版本。
這是Workflow Foundation 4的概述： MSDN Library of .NET 4 Workflow Foundation Overview您可以從那裏開始。
由於在WPF中使用，您必須異步調用您的工作流服務，否則將阻止WPF UI線程。
您可以進一步使用.NET 4.0的下一個版本的新Async API，但這只是一種語法糖，以減輕使用時間長的可怕異步編程。
因此，我不會推薦Workflow Foundation作爲業務規則驗證程序。您可以簡單地使用實體框架4中的數據註釋功能，從您的物理數據庫映射到您的業務實體層，然後再進行改造以添加業務邏輯和規則，速度更快。
如果您堅持，那麼您將不得不在任何地方使用異步代碼來實現WCF服務中工作流的複雜回調。
我不確定我是否已經做出了我想要做得非常清楚的事情。本質上，該計劃是將序列化的工作流傳遞到表示層，可以使用WorkflowInvoker類運行它們。特定演示對象的工作流程的輸入和輸出只能查看本地屬性包，而工作流由集合更改通知觸發。管理異步調用不是問題，因爲我們在表示層中已經有了一個這樣的機制。我不需要持續存在這個問題。 – LukeN
「傳遞的序列化工作流程」是什麼意思？正如我之前所說的，WPF的線程和WorkflowInvoker的線程是不同的。 如果您想基於ObservableCollection上的集合更改來觸發工作流，那麼WPF線程和WorkflowInvoker的往返運行仍然很昂貴，而如果您確實意味着驗證業務邏輯的規則如果使用工作流程，則相當矯枉過正。 –
目標是讓顯示規則推出瘦客戶機。目前，我們在地圖上控制圖標顯示的邏輯被硬編碼到客戶端，客戶端基於操作員角色，地圖上的不同圖標表現不同。這正在被一個通用的方案取代，我們有一個單一的圖標主機參數化BLL提供的規則。如果我們要使用WF，我們將在BLL上序列化工作流，並在客戶端上反序列化。然後，我們使用WorkflowInvoker運行一個描述圖標視覺行爲的工作流程，並給定已傳遞給客戶端 – LukeN
我想我會進一步調查，謝謝羅恩！ 你有這方面的表現簡介嗎？如果我有幾百個用戶呢？ –
如果您在客戶端執行業務規則，則用戶數量變得不那麼重要。那麼這只是一個從數據庫中檢索業務規則的問題，這應該不成問題。 –
奇妙的演示！ – Geert