去工作流还是不去工作流？

Question

我负责一组开发人员，他们将开始开发一个轻量级的保险索赔系统。该系统涉及许多手动任务和业务工作流，我们正在考虑使用Workflow (Windows4.0)。

商业领域的一个例子如下:投保人打电话给联络中心提出索赔。此“事件”触发两个子任务，这些子任务是手动并行操作的，可能需要很长时间才能完成；

1. 检查客户是否有欺诈行为-一种人工操作程序，操作人员打电话给各种信用公司，以检查和评估欺诈客户的潜力。从这里，子任务可以输入许多子状态(检查正在进行、引用检查失败、通过引用检查等)。
2. 将物品送到修理中心从这里子任务可以输入一些子状态(等待修复，正在进行中，修复，张贴等)。索赔只能在每个子任务的状态达到预定义状态(基于业务规则)之后才能进行。

表面上看来，Workflow确实是最好的技术选择；然而，在使用WF4.0时，我确实需要考虑一些问题。

1. 技能集--看看普通的开发人员技能集，我没有看到很多了解或了解工作流的开发人员。
2. 可维护性--社区内对WF4.0项目的支持似乎很少，再加上缺乏技能，引发了对可维护性的关注。
3. 进入障碍-我有一种感觉，Workflow有一个陡峭的学习曲线，它并不总是那么容易获得。
4. 新产品-由于工作流已经完全重写为.NET 4.0，我认为该产品是第一代产品，可能没有必要的稳定性。
5. 声誉-早期版本的Workflow没有受到很好的欢迎，被认为很难开发，并导致业务吸收不足。

因此，我的问题是，在这种情况下，我们是否应该使用Workflow (WF) 4.0，或者是否有替代技术(例如，简单状态机等)或者更好的工作流引擎？

Answer 1

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

从对业务问题的描述来看，WF4似乎是一个很好的匹配，所以没有问题。

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

大多数情况下，在执行这些长期运行的工作流类型时，使用IIS/WAS中托管的工作流服务是最好的路由。这使得解决版本控制问题也不困难，只需让第一条消息返回工作流版本，并使其成为每个后续消息的一部分。接下来，将WCF路由器放在基于版本的消息路由到正确端点的WCF路由器之间。最基本的是永远不要改变现有的工作流，总是创建一个新的工作流。

我对你有什么建议？不要在未知的，对你来说未经证实的技术上下大赌注。使用WF4在应用程序中做一个小的、非关键的部分。这样，如果它起作用，您可以扩展它，但是如果它失败了，您可以将它拔出，用更传统的.NET代码替换它。通过这种方式，您可以获得使用WF4的实际经验，而不必将决策建立在二手信息的基础上，并在此过程中学习到一种新的、强大的技术。如果可能的话，可以在WF4上学习一门课程，因为这将为您节省大量的时间来提高速度(无耻的自我插入这里)。

简单的状态机。我没有使用它，但我的印象是它是短期运行的，在内存中，状态机。WF4的主要优点之一是长期运行的方面。

Answer 2

我已经两次陷入这种困境，我选择了不使用工作流程基础。其中一些考虑(类似于你的)是

1. 涉及到的工作流要简单得多(状态机和顺序操作的组合)，在WF中这样做似乎对所涉及的工作过于费心。
2. 对于开发人员理解和有效使用WF的学习曲线被认为是很高的。描述有效转换和要采取的操作的状态转换表用于额外的灵活性，开发人员对此很满意，很容易理解概念和目的。
3. 业务流程更改的可能性很小，在转换表的帮助下，最基本的更改是可能的。转换中的更改将意味着数据库脚本，而操作的更改将导致新的发布/修补程序。然而，这种情况发生的可能性被认为很低。

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

Answer 3

在过去的几个月里，我们一直在使用WF4.0。我不得不说，用工作流的方式思考是很有挑战性的。不过，我可以告诉你这是值得的。我们开始的时候知之甚少。我们已经为WF4.0购买了一本初学者和专业书籍，这很有帮助。我本人在网上观看了许多视频，并跟踪了PDC 2009的重大新闻，内容涉及WF4.0，以及它与以前的一些糟糕版本有何不同。我们必须提出解决方案的一件主要事情是，我们可以在工作流中处理/我们的参数，而不必将我们的自定义活动绑定到特定的数据类型，以及如何在活动之间传递参数。我已经想出了一个很好的解决方案，到目前为止，我们的工作流体验一点也不坏。实际上，我们有一个越来越大的工作流密集型应用程序，我真的无法想象自己在一个不同的环境中解决它。我喜欢它所具有的视觉效果:它使我远离if/else等构造的细节，并使业务规则变得清晰，不会使您被迫深入代码行来了解发生了什么或如何修复某些bug。顺便说一句，我们所做的项目和你描述的非常相似，而且它是一个中等规模的项目。你可以从我的话中看出我喜欢它，我推荐它，虽然它包含一些风险，因为它是一种新技术，你必须想出一些创新的想法。

我的2美分..。