何时使用 Windows Workflow Foundation？ [关闭]答案

【问题标题】：When to use Windows Workflow Foundation? [closed]何时使用 Windows Workflow Foundation？ [关闭]
【发布时间】：2008-09-19 17:56:02
【问题描述】：

有些事情通过手工（代码）更容易实现，但有些事情通过 WF 更容易实现。看起来 WF 可以用来创建（几乎）任何类型的算法。所以（理论上）我可以在 WF 中完成所有逻辑，但对所有项目都这样做可能是个坏主意。

在什么情况下使用 WF 是个好主意，什么时候它会让事情变得更难？ WF 与手工编码的优缺点/成本是什么？

【问题讨论】：

似乎值得注意的是，在这些答案之后出现的 4.0 版本完全重写。

标签： .net workflow workflow-foundation

【解决方案1】：

只有满足以下任一条件时，您才可能需要 WF：

您有一个长时间运行的进程。
您的流程经常变化。
您需要流程的可视化模型。

更多详情，请参阅 Paul Andrew 的帖子：What to use Windows Workflow Foundation for?

请不要将 WF 与任何类型的可视化编程混淆或关联。这是错误的，可能导致非常糟糕的架构/设计决策。

【讨论】：

长时间运行过程的计量单位是什么？
@ivorykoder “进程”（真正的工作流程）可以在托管它的服务器重新启动后继续存在。
如果我有只满足#1的要求，那我选择WF是不够的。但是，如果要求包括 #2 和/或 #3，那么使用 WF 的情况会更强大。
我无法抗拒：只有当以下任何一项为真时，您才可能需要 WF：假。

【解决方案2】：

从来没有。你可能会后悔：

陡峭的学习曲线
难以调试
难以维护
没有提供足够的功能、灵活性或生产力提升来证明其使用的合理性
可以并且将会破坏无法恢复的应用程序状态

我唯一能想到使用 WF 的情况是，如果我想为最终用户托管设计器，而且可能那时还没有。

相信我，没有什么比您编写的代码更直接、强大或灵活的了，它可以完全按照您的需要去做。远离WF。

当然，这只是我的意见，但我认为这是一个该死的好。 :)

【讨论】：

-1 我尊重您对此的看法，但会非常感谢您对原因的专业解释。我看不出这种答案如何帮助任何人
我在对 WF4 生气的一天写了这个答案。我会用我遇到的问题更新我的答案。
我们从一位以WF为骨干的顾问那里继承了一个完成了一半的项目。它容易出错、无法重新启动的损坏的工作流、一个过时的版本控制系统，需要完整复制工作流以进行任何微小的更改、可怕的生成代码以及如此微妙的代码，以至于你必须带着孩子手套来处理它.在 6 个月的黄屏死机后，我们废弃了整个 WF 并改用 xml。我们做过的最好的决定。
这句话：“没有提供足够的功能、灵活性或生产力增益来证明使用它的合理性” 对我来说已经足够了。谢谢你。
仇恨者需要解释他们的仇恨。

【解决方案3】：

WF 生成的代码很恶心。 WF 带来的价值在于系统的可视化表示，尽管我还没有看到任何我不喜欢更简单的手工编码项目的东西（现在有 6-7 个与 WF 合作的项目） .

【讨论】：

【解决方案4】：

一般来说，如果您不需要持久性和跟踪功能（我认为这是主要功能），则不应使用 Workflow Foundation。

以下是我从经验中总结的 Workflow Foundation 的优缺点：

优势

持久性：如果您将有许多长时间运行的流程（想想几天、几周、几个月），那么工作流非常适合此。空闲的工作流实例会持久化到数据库中，因此不会占用内存。
跟踪：WF 提供了跟踪工作流中执行的每个活动的机制
*Visual Designer：我把它写成*，因为我认为这真的只对营销有用。作为一名开发人员，我更喜欢编写代码而不是视觉上将事物拼凑在一起。当您让非开发人员制作工作流程时，您通常会陷入混乱。

缺点

编程模型：您在编程功能方面确实受到限制。想想你在 C# 中拥有的所有伟大特性，然后忘记它们。 C#中简单的一两行语句变成了相当大的块活动。这对于输入验证来说尤其痛苦。话虽如此，如果您真的非常小心地只在工作流中保留高级逻辑，而在 C# 中保留其他所有内容，那么这可能不是问题。
性能：工作流占用大量内存。如果您在服务器上部署大量工作流，请确保您有大量内存。另请注意，工作流比普通 C# 代码慢得多。
陡峭的学习曲线，难以调试：如上所述。您将花费大量时间来弄清楚如何让事情发挥作用，并找出做某事的最佳方式。
工作流版本不兼容：如果您部署具有持久性的工作流，并且需要对工作流进行更新，则旧的工作流实例不再兼容。据说这在 .NET 4.5 中已修复。
您必须使用 VB 表达式（.NET 4.5 允许使用 C# 表达式）。
不灵活：如果您需要 Workflow Foundation 未提供的一些特殊或特定功能，请做好准备承受很多痛苦。在某些情况下，它甚至可能是不可能的。在你尝试之前谁知道？这里有很多风险。
没有接口的 WCF XAML 服务：通常使用 WCF 服务，您可以针对接口进行开发。使用 WCF XAML 服务，您无法确保 WCF XAML 服务已实现接口中的所有内容。您甚至不需要定义接口。（据我所知...）

【讨论】：

你的大部分缺点都不是真的，可能你对WF不够熟悉。 WF非常灵活。它让您编写可以在任何场景中重用的自定义活动（代码活动）。编写可重用的活动取决于您。想象一下，您将能够向业务顾问提供 GUI（带有 Workflow Designer Host 的 WPF 应用程序）以及活动工具集。现在他们可以根据需要更改和重新安排业务逻辑，并且不需要开发人员甚至编译新的应用程序。
现在想象一下，业务顾问必须使用您的自托管设计器，但没有 Intellisense！要么自己动手，要么必须使用 Visual Studio。我也觉得商业顾问甚至会很难理解一些概念，比如补偿、取消、异常处理。此外，任何远程复杂的逻辑都会导致巨大的工作流程变得无法维护（哦，你需要大量的内存来编辑这样的工作流程）。不过，您是对的，精心设计的自定义活动确实提供了相当大的灵活性。

【解决方案5】：

我发现使用工作流基础的主要原因是它在跟踪和持久性方面让您开箱即用。持久化服务很容易启动和运行，这带来了多个实例和主机之间的可靠性和负载分布。

另一方面，就像表单应用程序一样，工作流设计者推动您使用的代码模式很糟糕。但是您可以通过在工作流中不编写代码并将所有工作委托给其他类来避免问题，这些类可以比工作流更优雅地组织和单元测试。然后，您将获得设计师的酷炫视觉方面，而无需背后的意大利面条代码。

【讨论】：

【解决方案6】：

就我个人而言，我不喜欢 WF。对我来说，它的用处不如 WPF 或 WCF 等其他新的 MS 技术那么明显。

我认为 WF 将来会在商业应用程序中大量使用，但我没有使用它的计划，因为它似乎不适合我的项目工作。

【讨论】：

【解决方案7】：

我目前工作的公司建立了一个 Windows Workflow Foundation (WF)，他们选择使用它的原因是因为规则会经常更改，这将迫使他们重新编译各种 dll 等所以他们的解决方案是将规则放在数据库中并从那里调用它们。这样他们就可以更改规则，而不必重新编译和重新分发 dll 等。

【讨论】：

太糟糕了，常规 Web 服务和应用程序没有 .config 文件，无法读取数据库，也无法读取 XML 或包含规则的本地文件，无需重新编译。哦等等……

【解决方案8】：

Windows 工作流吸引了非编码 IT 经理、BA 等，就像它的表亲 BizTalk 一样，但在实践中，单元测试、调试和代码覆盖只是众多陷阱中的三个。你可以克服其中的一些，但你必须投入大量资金来实现这一目标，而使用纯代码你就能做到这一点。如果你真的有一个长期运行的需求，那么你可能需要更复杂的东西。我听说过关于能够在不重新编译 dll 的情况下将新的 xaml 文件投入生产的争论，但老实说，工作流将消耗的时间可以更好地用于改进您的持续集成，以达到编译部署不成问题的程度。

【讨论】：

【解决方案9】：

我会在需要使用工作流的任何环境中使用它，但是当它与 K2 甚至 SharePoint 2007 结合使用时，该平台的强大功能确实非常有用。与 BI 专家一起开发业务应用程序时，建议使用该平台，这通常只与简化和改进业务流程有关。

据记录，WF 是与 K2 的开发团队共同开发的，新的 K2 Blackpearl 是建立在 WF 之上的，MOSS 2007 和 WSS 3.0 的工作流引擎也是如此。

【讨论】：

【解决方案10】：

当您不想手动编写所有这些代码来维护可视化界面、跟踪和持久性时，选择 WF 是明智的选择。

【讨论】：

【解决方案11】：

几个月来，我一直在使用 Windows 工作流来开发自定义活动和重新托管的设计器，非开发人员可以使用它来构建工作流。 WF 非常强大，但它仅与开发人员构建的自定义活动一样好。归根结底，开发人员必须查看由非开发人员构建的工作流程以进行测试和调试，但从他们可以创建草案工作流程的角度来看，这太棒了。

此外，如果您有长时间运行的进程，WF 是一个很好的技术堆栈，可在您需要动态更新进程时使用 - 无需重新安装/下载或执行任何操作，只需将新的 XAML 文件添加到目录和您的架构应设置版本控制以废弃旧版本并使用新版本。

【讨论】：