为什么要使用Workflow？

Question

使用Windows工作流基础(WF)相对于滚动您自己的工作流框架有什么好处？

据我所知，WF只提供了一个非常简单的运行时引擎、一组类和一个用于定义工作流的模式(基于XAML)。所有困难的东西，如持久性、为运行时提供主机进程以及实现分布式工作流(跨进程)都由您决定。

另外，使用WF还有一个学习曲线.如果我们创建了自己的工作流框架，那么我们将简单地利用所有开发人员已经具备的技能(C#、XML、SQL等)。

我从一位传道者那里看到了这个博客，试图解释为什么我们应该使用WF：

为什么是工作流？

IMO没有做好令人信服的工作，因为它只是说它有助于“开发人员的生产力”，同时也承认开发人员可以使用他们自己的产品。

这里的聪明人能想出更好的理由吗？

来自以下答案的摘要：

我认为最有说服力的原因是，使用WF这样的标准化工作流平台(相对于滚动您自己的工作流平台)将允许您利用由MS和第三方提供的当前和未来的工具，如Visual。

另外，由于它是基于.NET的技术MS堆栈的一部分，它可能与未来的MS技术(如Azure)有更好的集成/迁移路径。

最后，拥有WF经验的开发人员的数量将增加(因为这将使他们在职业上受益)，从而将其转化为一种基本的商品技能，如SQL或HTML，这意味着将更容易找到能够在最短的提升时间内开始使用WF的人。

Answer 1

选择使用WF需要进行一些评估，我将尝试在这里提供一个比较全面的列表，说明优缺点。请记住，如果您要使用WF，请不要使用WF4+以外的任何东西，因为它是重写的，并且经过了它的前几个版本的显着审查。

优点

• 成本
• 灵活性
• 耐久性
• 可分配性
• 未来

成本

当将WF与其他路径进行比较时，需要注意WF的成本。这些路径可能包括BizTalk，一种基于开放源代码的框架，如对象流，甚至是滚动您自己的框架。记住，除非你需要一些非常简单的东西，否则每次滚动你自己的方法都是最昂贵的。因此，如果您需要相当大的功能，但也需要对源代码的控制，我会推荐一个开放源码框架。

灵活性

与BizTalk这样的框架相比，WF是一个非常灵活的框架。在WF中，您可以编写自己的自定义活动，并在框架之外执行您需要做的事情--这确实给了您所需的力量。

耐久性

WF包括一个非常强大的耐久性框架。它是持久的，因为工作流的状态可以被持久化，工作流可以被设置为空闲(以保存资源)，然后在稍后被召回。但是，因为它已经为整个主机场的持久性设置了更多的耐用性。换句话说，工作流可以在一台主机上启动，持久化，然后在另一台主机上被召回。

假设工作流是通过web服务(即WorkflowService)托管的。

可分配性

WF已经设置为跨主机场分发。

假设工作流是通过web服务(即WorkflowService)托管的。

未来

WF是BizTalk的替换编排引擎，实际上是由构建BizTalk的人员开发的。因此，WF在Microsoft堆栈中有着光明的前景。事实上，微软目前正致力于构建独立的组件，用组件取代BizTalk的所有功能。例如，Windows (更具体地说，是对IIS的插件)取代了当今BizTalk中存在的监视服务。

微软为什么要这么做？因为BizTalk并不适合云，因为它是一个大规模的安装，而它们正在构建的组件可以部署到云解决方案中。

缺点

• 灵活性
• 监控

灵活性

WF的灵活性也可能是它的缺陷，因为有时您不需要它提供的灵活性，因此花费更多的时间来构建您本来只想被包含的东西。有时，您需要一个框架，该框架需要做出大量的假设，并且可能不按照约定工作(例如MVC)。但是，一般来说，当将WF4框架与Ron提供的开源扩展耦合时，我发现情况并非如此。

监控

对WF的监测还很年轻，这是其最大的缺陷。但是，随着时间的推移，这将很快地提高的，同时您也可以使用自定义跟踪机制构建自己的监控工具。

资源

您最好的资源是罗恩·雅各布斯。我从未见过比他更愿意帮助不得不使用微软框架的开发人员社区的人。相信我，他通过很多渠道提供了大量关于WF的信息，只要在Google上查看就可以了。

Answer 2

我认为倾向于在另一个工作流框架上使用WF的主要原因是：

1. 微软正在支持它作为框架的核心部分，因此它可以/将更容易地集成到他们的其他技术，如Sharepoint和Azure“云应用程序”
2. 该工具可能会在另外几个版本中得到改进，并且非常精巧，这将提高开发人员的工作效率。

Answer 3

我不得不在我的工作中创建工作流活动，我甚至不能告诉你答案。

一个不太有效的原因是无效的值/输入可以在工作流图的设计时被确定和拒绝，因此编译时错误基本上不存在(假设您编写的所有样板代码都没有编译时错误)。