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

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

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

仅当满足以下任一条件时，才需要WF：

1. 您有一个长期运行的过程。
2. 您有一个经常更改的过程。
3. 您需要一个可视化的过程模型。

有关更多详细信息，请参阅Paul Andrew的文章：Windows Workflow Foundation可以用于什么？

请不要将WF与任何形式的可视化程序混淆或联系起来。这是错误的，并且可能导致非常糟糕的架构/设计决策。

决不。您可能会后悔：

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

我唯一可以设想使用WF的时间是，如果我想为最终用户托管设计人员，甚至可能不是这样。

相信我，没有什么比您编写的代码完全能够直接，强大或灵活地完成所需的工作了。远离WF。

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

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

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

以下是我从经验中学到的Workflow Foundation的优缺点：

优点

• 持久性：如果您将要有许多长时间运行的流程（请考虑数天，数周，数月），那么工作流将非常有用。空闲的工作流实例将持久保存到数据库中，因此不会占用内存。
• 跟踪：WF提供了一种机制来跟踪工作流中执行的每个活动
• *视觉设计师：我将其作为*，因为我认为这仅对营销有用。作为开发人员，我更喜欢编写代码，而不是视觉上将它们组合在一起。而且，当您有非开发人员制作的工作流时，通常会导致混乱的局面。

缺点

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

我发现使用工作流基础的主要原因是，它在跟踪和持久性方面为您带来了无穷的收益。持久性服务的启动和运行非常容易，它可以在多个实例和主机之间带来可靠性和负载分配。

另一方面，就像表单应用程序一样，工作流设计人员向您推送的代码模式也很糟糕。但是，您可以通过在工作流中不编写任何代码并将所有工作委托给其他类来避免问题，这些类可以比工作流更优雅地进行组织和单元测试。然后，您将获得设计人员的出色视觉效果，而无需担心背后的意大利面条代码。

就个人而言，我没有在WF上出售。对我来说，它的作用并不像WPF或WCF等其他新的MS技术那么明显。

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

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

Windows Workflow像表弟BizTalk一样诱使非编码IT经理，BA等，但是实际上，单元测试，调试和代码覆盖只是众多陷阱中的三个。您可以克服其中的一些，但是您必须投入大量资金来实现这一目标，而使用简单的代码就可以做到。如果您确实有长期的需求，那么您可能需要更复杂的东西。我已经听说过有关能够在不重新编译dll的情况下将新的xaml文件放入生产环境的争论，但是说实话，工作流将消耗的时间可以更好地用于改进持续集成，以至于编译部署不会成为问题。

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

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

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

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

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