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

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

解决方案

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

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

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

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

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

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

• 我们有一个长期运行的过程。
• 我们有一个经常更改的过程。
• 我们需要一个可视化的过程模型。

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

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

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

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

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