使用 Windows Workflow Foundation(WF) 作为演示规则引擎是否明智？答案

【问题标题】：Is it sensible to use Windows Workflow Foundation(WF) as a presentation rules engine?使用 Windows Workflow Foundation(WF) 作为演示规则引擎是否明智？
【发布时间】：2011-09-19 08:32:28
【问题描述】：

我正在开发一个 n 层应用程序，该应用程序需要在演示端使用规则引擎。

我需要将显示规则从数据库加载到 BLL 层并将它们传递给客户端。例如。当 propertyX 为 true 时，项目 A 以红色轮廓显示，当 propertyY 为 true 时以白色轮廓显示 && 当两者都不为 true 并且您没有管理员角色时，它应该被隐藏

BLL 最终会在某个时候成为规则驱动的，但我们将首先从那里的现有客户端/服务器应用程序迁移硬编码逻辑。

看看 WF，它似乎允许我创建和序列化可以托管在 BLL 或表示层上的工作流。

我预计会有大量规则，因为不同的用户角色会为暴露于表示层的 50 多种类型的实体获得稍微不同的规则集。

这是个好主意吗？

定义 DSL 并自己管理一切会更简单吗？

【问题讨论】：

标签： wpf wcf workflow-foundation workflow-foundation-4 n-tier-architecture

【解决方案1】：

有两件事你应该知道。

首先，请记住，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 服务中工作流的复杂回调。

【讨论】：

我不确定我是否已经把我想做的事情说得很清楚了。本质上，该计划是将序列化的工作流传递给可以使用 WorkflowInvoker 类运行它们的表示层。特定表示对象的工作流的输入和输出只会查看本地属性包，工作流由集合更改通知触发。管理异步调用不是问题，因为我们已经在表示层中为此提供了一种机制。我不需要让工作流持续存在。
“已通过序列化工作流程”是什么意思？前面说了，WPF的线程和WorkflowInvoker的线程是不一样的。如果您想基于 ObservableCollection 上更改的集合来触发工作流，那么 WPF 线程和 WorkflowInvoker 的往返仍然很昂贵，而如果您真的是指使用工作流验证业务逻辑的规则，那就太矫枉过正了。
目标是将显示规则推出瘦客户端。目前，控制我们地图上图标显示的逻辑被硬编码到客户端类中，其中地图上的不同图标根据操作员角色表现不同。这被一个通用方案所取代，其中我们有一个使用 BLL 提供的规则参数化的单个图标主机。如果我们要使用 WF，我们将在 BLL 上序列化工作流并在客户端反序列化。然后，我们使用 WorkflowInvoker 运行一个描述图标视觉行为的工作流，给定已传递给的属性
客户端。从 [msdn][msdn.microsoft.com/en-gb/library/dd465567.aspx]WorkflowInvoker.Invoke() 在调用线程（可能/可能不是我的 ui 线程）上同步运行。如果这将是足够的性能（考虑到地图上可能出现的大量图标），它可以让我们以一种很好的方式定义这些显示规则，而无需编写自定义规则引擎（好处是它们很容易在层之间传递并存储到数据库）。注：调用之间的持久性不是问题。

【解决方案2】：

实际上，我认为 Workflow 非常适合这种情况。有很多人在构建应用程序，工作流在客户端执行，我们通过 WorkflowApplication 对此提供了很好的支持，它支持后台线程上的工作流。

事实上，我在这个场景下写了Introduction To State Machine Hands on Lab。在该应用程序中，具有 MVVM 模式的 WPF 客户端使用模型中的工作流来控制模拟 ATM 机的行为。

【讨论】：

我想我会进一步调查，谢谢罗恩！你有这方面的表现吗？如果我有数百个用户怎么办？
如果您在客户端执行业务规则，那么用户数量就变得不那么重要了。然后，只需从数据库中检索业务规则，这应该不是问题。