C# 要创建工作流还是不创建工作流？

我负责一个开发团队，他们将开始开发轻量级保险索赔系统。该系统涉及大量手动任务和业务工作流，我们正在考虑使用Windows工作流（.NET 4.0）

业务领域的示例如下所示： 保单持有人致电联系中心提出索赔。此“事件”触发两个子任务，这两个子任务是手动并行执行的，可能需要很长时间才能完成

检查客户是否存在欺诈行为–操作员致电各信贷公司检查和评估欺诈客户潜力的手动流程。从这里，子任务可以输入多个子状态（正在检查、参考检查失败、参考检查通过等）

将项目发送至维修中心–保单持有人提出索赔的项目被发送至维修中心进行修复的手动流程。从这里，子任务可以输入多个子状态（等待修复、进行中、修复、发布等）。 声明只能在每个子任务的状态达到预定义状态（基于业务规则）后继续 从表面上看，工作流确实是最佳的技术选择；不过，在使用WF4.0时，我确实有一些顾虑

技能集–从开发人员的平均技能集来看，我没有看到许多了解或了解工作流的开发人员

可维护性——社区内似乎很少有人支持WF 4.0项目，再加上缺乏技能，这引起了对可维护性的担忧

进入壁垒——我感觉Windows工作流有一条陡峭的学习曲线，学习起来并不总是那么容易

新产品–由于为.NET 4.0完全重写了工作流，我认为该产品是第一代产品，可能没有必要的稳定性

声誉–以前版本的工作流不受欢迎，被认为难以开发，并导致业务利用率低下

---

我的问题是我们应该使用Windows工作流（WF）4来解决这个问题，或者是否有一个替代的技术（例如，等等），甚至是一个更好的工作流引擎使用？

< P>我已经遇到了这种两难的时候，我选择不使用工作流基础。一些考虑因素（与您的类似）是

所涉及的工作流程要简单得多（状态机和顺序操作的组合），在WF中完成这项工作似乎有点过分了

开发人员理解和有效使用WF的学习曲线被认为很高。状态转换表描述了有效的转换和要采取的操作，用于增加灵活性，开发人员可以轻松地理解其概念和目的

业务流程更改的机会很小，借助于转换表，可以很容易地进行基本更改。转换中的更改将意味着数据库脚本，而操作中的更改将导致新的版本/补丁。然而，发生这种情况的可能性被认为很低

---

13-14个月后回顾，我仍然认为不使用WF的决定是正确的。在国际海事组织，WF在工作流程可能发生变化和/或业务规则可能发生变化的情况下是有意义的。WF允许将工作流隔离在单独的文件中，因此用户可以更简单地对其进行配置

我在WF3.5中做了三个项目，我不得不说这并不容易。它迫使你以全新的方式思考，尤其是在坚持的时候。更新包含数百个不完整持久化工作流的应用程序是一项挑战。序列化中的单个破坏性更改会使它们全部崩溃。引入同一库的多个版本以支持新的和旧的运行工作流是很常见的。这很有挑战性

我还没有尝试WF 4.0，但根据BizTalk和WF 3.5的经验，我认为它将是类似的

无论如何，您可以采取的最佳方法是进行概念验证。从您的需求中选取一个WF，并尝试在WF4.0中实现它。您将花一些时间使用它，但您将证明在WF 4.0中是否能够做到这一点，以及是否有任何明显的好处

---

如果您决定使用WF 4.0，我坚持要求您检查是否可以将WF作为承载在Windows AppFabric中的WCF服务运行。AppFabric为承载WFs提供了一些现成的功能。

我已经完成了几个WF4项目，让我们看看是否可以在其他答案中添加任何有用的信息

从您的业务问题的描述来看，WF4似乎是一个很好的匹配，因此没有问题

关于你的担忧，你是对的。基本上，WF4是一种新产品，缺少一些重要功能，并且有一些粗糙的边缘。有一个学习曲线，你必须做一些不同的事情。主要的一点是长时间运行和序列化，这是一般开发人员不习惯的，需要一些思考才能正确，因为我经常听到人们在序列化实体框架数据上下文时遇到问题

大多数情况下，使用IIS/WAS中托管的工作流服务是执行这些长时间运行的工作流类型的最佳途径。这使得解决版本控制问题也不难，只要让第一条消息返回工作流版本，并将其作为后续消息的一部分即可。接下来，将WCF路由器置于两者之间，根据版本将消息路由到正确的端点。基本原则是永远不要更改现有工作流，始终创建一个新的工作流

那我给你什么建议呢？ 不要在一项未知的、对你来说未经证实的技术上下大赌注。使用WF4执行一个小的、非关键的应用程序。这样，如果它能工作，你可以对它进行扩展，但如果它失败了，你可以把它撕下来，用更传统的.NET代码替换它。这样你就得到了r