何时使用 Windows Workflow Foundation？

小开

WF 生成的代码非常糟糕。WF 带来的价值在于系统的可视化表示，尽管我还没有看到任何东西(现在有6-7个项目正在与 WF 一起工作，我已经参与其中) ，我不会更喜欢一个更简单的手工编码项目。

小开

就我个人而言，我不喜欢 WF。对我来说，它的实用性并不像其他新的 MS 技术(如 WPF 或 WCF)那样显而易见。

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

小开

我发现使用工作流基金会的主要原因是它在跟踪和持久性方面为您带来了多少开箱即用的东西。很容易启动和运行持久性服务，从而在多个实例和主机之间实现可靠性和负载分配。

另一方面，就像表单应用程序一样，工作流设计者推动你走向的代码模式是不好的。但是您可以通过在工作流中不编写任何代码并将所有工作委托给其他类来避免问题，这些类可以比工作流更加优雅地进行组织和单元测试。然后你就可以看到设计师很酷的视觉效果，而不需要背后那些意大利面条式的代码。

小开

最佳答案

只有符合下列任何一项条件时，你才可能需要 WF:

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

更多细节，请参见 Paul Andrew 的文章: 用 Windows Workflow Foundation 做什么？

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

小开

我会在任何需要使用工作流的环境中使用它，但是当与 K2或甚至 SharePoint2007结合使用时，这个平台的力量是真正有用的。在使用 BI 专家开发业务应用程序时，建议使用该平台，这通常只与简化和改进业务流程有关。

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

小开

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

小开

永远不会。你可能会后悔:

学习曲线陡峭
很难调试
很难维持
不能提供足够的动力、灵活性或生产力来证明它的使用是合理的
可以并将损坏无法恢复的应用程序状态

我唯一能够想到使用 WF 的时候是，如果我想为终端用户托管设计器，甚至可能不是那个时候。

相信我，没有什么能像您所编写的代码那样简单、强大或灵活，可以完成您所需要的任务。离 WF 远点。

当然，这只是我个人的观点，但我认为这是一个非常好的观点。 :)

小开

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

小开

一般来说，如果您不需要持久性和跟踪特性(在我看来这是主要特性) ，那么您就不应该使用 Workflow Foundation。

以下是我从自己的经历中总结出来的 Workflow Foundation 的优点和缺点:

好处

持久性: 如果您将有许多长时间运行的流程(想想几天、几周、几个月) ，那么工作流非常适合这种情况。空闲的工作流实例被持久化到数据库中，这样它就不会占用内存。
跟踪: WF 提供了跟踪工作流中执行的每个活动的机制
视觉设计师: 我把这个作为一个 * ，因为我认为这是真的只有在营销目的有用。作为一名开发人员，我更喜欢编写代码，而不是视觉化地将事物拼凑在一起。当您有一个非开发人员制作工作流时，您通常会以一个巨大的混乱结束。

缺点

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

小开

Windows Workflow 像它的兄弟 BizTalk 一样吸引非编码 IT 经理、 BA 等等，但在实践中，单元测试、调试和代码覆盖率只是许多陷阱中的三个。您可以克服其中的一些问题，但是您必须投入大量资金才能实现这一点，而使用普通代码只能实现这一点。如果您真的有一个长期运行的需求，那么您可能需要一些更复杂的东西。我听说过这样的争论，即能够在不重新编译 dls 的情况下将新的 xaml 文件放到生产环境中，但老实说，工作流所消耗的时间可以更好地用于改进持续集成，使得编译后的部署不成为问题。

小开

我已经使用 Windows 工作流数月了，现在开发定制活动和重新托管的设计师，非开发人员可以使用它们来构建工作流。WF 非常强大，但它只能与开发人员构建的自定义活动一样好。归根结底，开发人员必须查看由非开发人员构建的工作流来进行测试和调试，但是从他们可以创建草稿工作流的角度来看，这是非常棒的。

此外，如果你有长时间运行的进程，当你需要动态更新进程时，WF 是一个很好的技术栈——不需要重新安装/下载或者做任何事情，只需要将新的 XAML 文件添加到一个目录，你的架构应该建立版本控制，废弃旧的，使用新的。