我正在处理在演示文稿末尾需要规则引擎的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