我正在开发一个需要在演示文稿端使用规则引擎的n层应用程序。
我需要将数据库中的显示规则加载到BLL层并将它们传递到客户端。例如。当propertyX为真时，项目A以红色标出，当属性为真时，项目A以白色标出＆amp;＆amp;如果两者都不存在且您没有Admin角色
，则应该隐藏它BLL最终将成为规则驱动，但我们将首先从现有的客户端/服务器应用程序迁移硬编码逻辑。
看看WF，它似乎允许我创建和序列化我可以在BLL或表示层上托管的工作流。
我希望会有大量的规则，因为不同的用户角色会为暴露于表示层的50多种类型的实体获得略微不同的规则集。
这是个好主意吗？
定义DSL并自行管理所有内容会更简单吗？
答案 0 :(得分：4)
你应该知道两件事。
首先，请记住，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作为业务规则验证程序。您可以简单地使用Entity Framework 4中的数据注释功能，从物理数据库映射到业务实体层，然后进一步重新构建以添加业务逻辑和规则，并且速度更快。
如果你坚持，那么你将不得不在任何地方使用异步代码来实现WCF服务中工作流的复杂回调。
答案 1 :(得分：3)
实际上我认为Workflow非常适合这种情况。有许多人构建了工作流执行客户端的应用程序，我们通过支持后台线程工作流的WorkflowApplication为此提供了很好的支持。
事实上，我用这种情况写了Introduction To State Machine Hands on Lab。在该应用程序中，具有MVVM模式的WPF客户端使用模型中的工作流来控制模拟ATM机的行为。
