我正在评估WF在网络上的业务应用程序中的使用情况，我很想听听有关该技术的一些第一手资料。

在这里，我的主要兴趣是提高项目的可维护性，或者在处理经常变化的复杂流程时提高开发人员的生产率。

我真的很喜欢WF的概念，但是它似乎相对未知，而且我遇到的许多较旧的评论都提到，一旦我们了解它，它就会变得极其复杂。

如果它被过度设计，以至于对于中小型项目来说是不可用的(或者不利的折衷)，那是我需要知道的事情。

当然，它自2006年底以来就已淘汰，所以也许它已经成熟了。如果是这样，那是另一条非常有用的信息！

提前致谢！

解决方案

这实际上取决于我们要使用它做什么。我只使用了一点，但是与更成熟的产品(例如MetaStorm(从技术上我知道它是BPM，但仍然有工作流程组件))，Process Choriographer和IBM MQ工作流程相比，没有可比性。只是还不够成熟。另一方面，在其他人没有的情况下它是免费的，并且可能可以完成工作。我不知道是否要对它进行数百万美元的手术，但是如果是较小的手术，我会再给它一个机会。我们要面对的真正障碍是改变思维过程。如果我们之前没有使用过状态系统的开发人员，那将是一个真正的障碍。

我们已经在大型的SharePoint应用程序中使用了WF，我可以说还可以。它具有强大的功能和灵活性。而且，正如Kevin提到的那样，一旦掌握了工作流的基本概念，就可以使用它进行几乎任何我们想做的事情。

另一方面，它有一些非常严重的问题，例如缺少版本控制，这将来可能会严重损害应用程序。我们被迫部署多达三个并行版本的相同工作流程，分别称为xxx-v1，xxx-v2和xxx-v3，以保持较旧的实例运行并让新实例使用更新的版本。一个真正的痛苦的屁股。哦，那里还有一些非常不直观的概念(相关标记，wtf ??)

我认为MS WF是一个低级工作流库，而不是像K2这样的成熟的企业工作流产品。它使我们能够构建启用了工作流程的应用程序，但它本身不是工作流程应用程序。尽管我们不得不围绕它建立很多自己的基础架构(发布/订阅框架，worlkflow生命周期管理器等)，但我以这种身份获得的体验还是很积极的。那里的许多文档都非常简单，没有涵盖基于MS WF的企业工作流应用程序的构建。

Brian，我无法回复评论，但是无论如何，通过版本控制，我的意思是在不破坏已经运行的实例的情况下更改工作流的基础代码，并优雅地将更新应用于现有工作流。我不确定"储备" WF，但至少在SharePoint环境中没有工作流版本的概念，因此新版本必须作为完全不同的工作流进行部署，这成为维护的噩梦。
这与"补液"无关，补液是我们在某个事件或者状态更改后将"休眠"工作流恢复活动的过程。这由工作流运行时透明地处理。

WF ist已集成到SharePoint(WSS 3.0)中，并且我为各种SharePoint网站创建了很多工作流，因此我可以介绍一下我在SharePoint中WF的经验。与其他工作流框架相比，WF得分高。它很稳定(我没有遇到过任何神秘的错误)，工作流非常容易设计(由于Visual Studio中的工作流设计器)，我们不仅可以使用顺序工作流，还可以使用状态机工作流。

当然，这并不是完美的，开发人员肯定需要一些时间来理解(即活动模型)的概念；但即使对于"小任务"，它也绝对可用。

相关问题：何时使用Windows Workflow Foundation？我的回答是：

You may need WF only if any of the
  following is true:
  
  
  You have a long-running process.
  You have a process that changes frequently.
  You want a visual model of the process.
  
  
  For more details, see Paul Andrew's
  post: What to use Windows Workflow Foundation for?
  
  Please do not confuse or relate WF
  with visual programming of any kind.
  It is wrong and can lead to very bad
  architecture/design decisions.

因此，如果我们有这样的要求，那么WF是一个不错的选择。当然，这是相对复杂的，但要提及的是，要解决的问题也很复杂(有时非常复杂)。恕我直言，例如，要对添加了事件处理程序的对象进行脱水/复水操作非常复杂(当对象不在内存中时可以触发事件)。

我无法判断我们所说的"中小型项目"是什么意思，但是总的来说，我想说的是，如果项目至少具有以上列出的两个要求，那么我们可以考虑使用WF作为解决方案。

Windows Workflow Foundation是一个非常强大的产品，但在其第一个版本中仍然非常有用：-(

使用的主要原因包括：

• 可视化地建模业务需求。
• 将业务逻辑与业务规则分开，并将规则外部化为XML文件。
• 通过将工作流外部化为XML文件，将业务流程与应用程序分开。
• 创建长时间运行的流程，并具有自动响应能力，如果长时间未发生任何反应。例如，发票未付。
• 长期运行的工作流的自动持久性可降低资源使用率，并允许进程和/或者计算机重新启动。
• 自动跟踪工作流程，以帮助满足业务需求。

WF是作为库/框架提供的，因此大多数时候我们需要编写实例化WF运行时的主机。也就是说，使用IIS托管的WCF是可行的解决方案，并且可以节省大量工作。但是，WCF / WF耦合还不够完善，需要进行一些认真的工作。有关更多详细信息，请参见此处http://msmvps.com/blogs/theproblemsolver/archive/2008/08/06/using-a-transactionscopeactivity-with-a-wcf-receiveactivity.aspx。期望在下一版本中有很多更改/增强。

WF(和WCF)对于Microsoft产生的许多新内容非常重要。在PDC期间，我们会期待一些有趣的公告。

顺便说一句，保持工作流的多个版本运行需要一些工作，但这主要是标准的.NET。我只是从此处开始撰写了一系列有关该主题的博客文章：http://msmvps.com/blogs/theproblemsolver/archive/2008/09/10/versioning-long-running-workfows.aspx

关于对业务需求进行可视化建模。
从理论上讲，这可以很好地实现意图和实现的分离。但是在实践中，纯粹出于技术原因，我们将在工作流中放弃大量额外的活动，而这违背了目的，因为我们必须告诉业务分析师忽略一半的形状和线条。

从未尝试过WFF，但我记得曾读过Leon Bambrick撰写的有关WFF的文章，他基本上说整个软件开发工具类型都是胡说八道。可能会决定一种方法。

我们有一个工作中的项目，我参与了工作流的使用。
(来自管理层)的想法是，我们程序员将编写工作流活动以及"引擎"和框架。然后，非程序员将把自己的工作流编译成dll，然后由引擎自动加载，从而处理其余所有工作。

管理层通过使用Workflow来帮助开发软件的非程序员想法被出售，这几乎完全是在浪费时间。我们试图用该项目解决的问题相对复杂，并且从一开始就知道该软件几乎必须不断修改(其计算取决于其他公司和政府)。

最终结果是，我们无法使Workflow模块具有足够的通用性，以供其他任何人使用。因此，程序员是那些被迫使用工作流的人，所有工作流都被我们所束缚了。

去年，我们与WF一起完成了一个工作应用程序，该应用程序现在已成为一个庞大的系统的基础，该系统被一家大型银行用于抵押程序。 pe流程有许多步骤，从客户申请到信用批准开始。

尽管这是成功的，但一路走来有很多问题和危机。对于任何较小规模的项目，这都不值得麻烦。

在过去的几个月中，我一直在使用Workflow 4.0，尽管印象深刻，但我发现它非常难学。

对于最新版本(.NET 4.0 RC随附)，网络上几乎没有文档，任何书籍都没有，也没有可用的培训课程。我只发现了与现已失效的3.0版本有关的文章。甚至MSDN文档也没有什么实际意义。

工作流设计者不像应该以任何方式那样直观，因此学习非常困难。我不得不依靠一个人在StackOverflow上的答案(感谢Maurice！)，如果没有他的帮助，我将被塞满。

因此，在总结，我认为它有潜力，但你会很生气，以了解它仍然等待更多的培训，文档和书籍，否则你会进入它瞎了！

很难学。相当灵活。不要与仅面向程序员的可视化工具相混淆。不知道我是否喜欢依赖属性方法。