我的主要兴趣在于提高项目的可维护性，也许在处理经常变化的复杂过程时提高开发人员的生产力。
我真的很喜欢WF的想法，但是它似乎是相对未知的，许多旧的评论，我遇到提到，它是绝对复杂，一旦你进入它。
如果它被过度设计到它对于中小型项目不可用(或一个不好的权衡)的点，这是我需要知道的东西。
当然，它已经从2006年年底以来，所以也许它已经成熟。如果是这样，这是另一个信息，将是非常有帮助！
提前致谢！
解决方法
使用的主要原因包括：
>视觉建模业务需求。
>将业务逻辑与业务规则分离，并将规则外部化为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)对于许多微软的新东西来说都是核心。你可以期待在PDC期间一些有趣的公告。
BTW保持工作流运行的多个版本需要一些工作，但是主要是标准的.NET。我刚刚做了一系列的博客文章从这里开始：http://msmvps.com/blogs/theproblemsolver/archive/2008/09/10/versioning-long-running-workfows.aspx
关于视觉建模业务需求。在理论上，这与分离意图和实现相当好。然而，在实践中，您将会在工作流程上出现一些额外的活动，纯粹是出于技术原因，而且这样的失败的目的，因为你必须告诉业务分析师忽略一半的形状和线条。
