C# 为什么使用Windows工作流？ 使用Windows工作流基金会（WF）与滚动自己的工作流框架有什么好处？

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

此外，还有一个学习曲线使用WF。。。如果我们创建自己的工作流框架，我们只需利用所有开发人员已经具备的技能（C#、XML、SQL等）

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

在我看来，它并没有很好地说服人，因为它只是说它有助于“开发人员的生产力”，同时承认开发人员可以自己开发

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

下面给出的答案总结：

---

我认为最有说服力的原因是，使用标准化的工作流平台，如WF（而不是自己滚动），将允许您利用MS和第三方提供的当前和未来工具，如Visual Designer

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

---

最后，拥有WF经验的开发人员数量将增加（因为这将使他们从职业角度受益），使其成为基本的商品技能，如SQL或HTML，这意味着在最短的启动时间内找到可以开始使用它的人将变得更容易。

Visual Studio中有一些相当不错的设计器支持，我不想自己使用，它是一个由别人而不是我支持的框架，这意味着有人修复了架构缺陷并进行了主要测试，让我只测试我的工作流程。我的意思是，我可以推出我自己版本的GDI+调用，但我不愿意。我自己的序列化框架、XML解析器或.NET框架的某些其他元素也是如此

---

归根结底，这些东西是作为工具包提供的。您是否选择使用工具完全取决于您正在解决的问题、工具的适用性以及您实现目标所需的时间和资源。

我必须在工作中创建工作流活动，我甚至无法告诉您答案

---

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

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

Microsoft支持将其作为框架的核心部分，因此它可以/将更容易地集成到Sharepoint和Azure“云应用程序”等其他技术中

该工具可能会有所改进，并且在其他几个版本中会非常流畅，这将提高开发人员的生产率

---

简短回答：它是免费的，而且它能完成任务。如果你能推出一个更好的工作流管理框架，并想把时间花在它上面，那就千方百计去做吧。但是考虑到<强>你的时间值金钱，那么你愿意投入多少钱来建立一个更好的管理工作流的框架？我看那会越来越贵

---

另外，我非常确定持久性（到磁盘或SQL）是开箱即用的

选择使用WF需要一些评估，我将尝试在这里提供一个相当全面的列表，列出其优缺点。请记住，如果要使用WF，请不要使用WF4+以外的任何东西，因为它已被重写，并且经过了比其前身更严格的审查

赞成的意见

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

成本 将WF与其他路径进行比较时，必须注意WF的成本。这些路径可能包括一个基于开源代码的框架，比如，甚至是您自己的框架。请记住，除非你需要一些非常简单的东西，否则每次滚动你自己的将是最昂贵的方法。因此，如果您需要一个相当大的功能块，而且还需要控制源代码，我建议您使用一个开源框架

灵活性 与BizTalk等框架相比，WF是一个非常灵活的框架。在WF中，您可以编写自己的自定义活动，并在框架之外执行您需要执行的操作—这确实为您提供了所需的功能

耐久性 WF包括一个非常强大的耐久性框架。它是持久的，因为工作流的状态可以持久化，工作流可以设置为空闲（以保留资源），然后在以后调用但是，这种耐用性更进一步，因为它已经为整个宿主农场的耐用性设置好了。换句话说，工作流可以在一台主机上启动、持久化，然后在另一台主机上调用

假设工作流通过web服务（即WorkflowService）托管。

可分配性 WF已设置为跨主机场分发

假设工作流通过web服务（即WorkflowService）托管。

未来 WF是BizTalk的替代编排引擎，实际上是由构建BizTalk的人开发的。因此，WF在Microsoft堆栈中有着光明的前景。事实上，目前Microsoft正在构建单个组件，以用组件替换BizTalk的每个功能。例如，（更具体地说是IIS插件）是BizTalk中现有监控服务的替代品

微软为什么要这样做？贝卡