使用工作流程还是不使用工作流程？

Question

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

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

1. 检查欺诈客户- 运营商将调用各种信用公司来检查和评估欺诈客户的潜力。从这里开始，子任务可以进入许多子状态（检查进行中、参考检查失败、参考检查通过等）
2. 将项目发送到维修中心- 申报索赔的项目被送到维修中心进行修复。从这里开始，子任务可以进入许多子状态（待修复、正在处理、已修复、已发布等）。只有当每个子任务的状态达到预定义状态（基于业务规则）时，索赔才能继续进行。

表面上看，Workflow确实是最好的技术选择；但是我对使用WF 4.0有一些担忧。

1. 技能集- 查看平均开发人员技能集，我并没有看到很多了解或掌握Workflow的开发人员。
2. 可维护性- 社区中似乎很少支持WF 4.0项目，再加上缺乏技能集，对可维护性存在担忧。
3. 入门门槛- 我有一种感觉，Windows Workflow具有陡峭的学习曲线，不总是那么容易掌握。
4. 新产品- 因为Workflow已完全重写为.NET 4.0，我认为该产品是第一代产品，可能没有必要的稳定性。
5. 声誉- 先前版本的Workflow未受欢迎，被认为难以开发，并导致业务接受度低。

所以我的问题是，我们是否应该在这种情况下使用Windows Workflow (WF) 4.0，还是有另一种替代技术（例如Simple State Machine等），或者甚至有更好的工作流引擎可供使用？

- Kane

---

好像大家都处于同一条船上......有好几个赞但没有回复...... ;) - CJM

呵呵呵...也许缺乏回答是因为星期五综合症？ - Kane

关于WF4的大量资源，请查看http://endpoint.tv - Ron Jacobs

我面临着类似的决定，并倾向于选择WF。这篇帖子已经一年了。你选择了WF吗？如果选择了，你还会再做一次吗？ - John Laffoon

不，我决定不使用WF4，并且很高兴我做出了这个决定-因为掌握WF4知识的人太少了，而且业务经常改变主意，使用WF4将使得这个系统难以维护和支持。 - Kane

@Kane - 你漏掉了一个有趣的细节：最终你选择做了什么而不是使用WF4？ :) - Peter Lillevold

Answer 1

我已经完成了几个WF4项目，所以让我们看看是否可以为其他答案添加一些有用的信息。

根据您的业务问题描述，似乎WF4是一个很好的选择，所以没有问题。

关于您的顾虑，您是正确的。基本上，WF4是一个新产品，缺少一些重要的功能，并且存在一些不足之处。有一个学习曲线，您必须做出一些不同的事情。主要问题是长时间运行和序列化，这是普通开发人员不习惯的，需要一些思考才能正确处理，因为我经常听到人们在序列化实体框架数据上遇到问题。

大多数情况下，在IIS/WAS中托管工作流服务是处理这些长时间运行工作流的最佳方法。这使得解决版本问题也不难，只需让第一个消息返回工作流版本，并将其作为每个后续消息的一部分。然后将WCF路由器放在中间，根据版本将消息路由到正确的终点。基本原则是永远不更改现有工作流程，而始终创建新工作流程。

那么我的建议是什么呢？ 不要在未知和对您未经验证的技术上进行大赌注。使用WF4执行一个小的、非关键的应用程序部分。这样，如果它可以正常工作，您可以扩展它，但如果失败，您可以将其删除并用更传统的.NET代码替换它。这样，您就可以获得真正的WF4体验，而不是基于二手信息做出决定，并在此过程中学习新的强大技术。如果可能的话，请参加WF4课程，这将节省您很多时间（无耻地自我推广here）。

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

- Maurice

---

我同意，WF4 让我彻底崩溃了。当时我后悔（不是我的决定）使用它，我们应该等待 .NET 4.5。如果在工作流中出现错误并导致错误，解决 WF 设计中的错误后，您无法轻松地将其与已持久化的长时间运行的工作流相关联。您基本上必须重新开始。3.5 版本具有 DynamicUpdates，尽管它们在 4.0 版本中将其删除了。在我的经验中，4.5 版本中的动态更新和并行版本控制对于 Windows WF 解决方案的成功至关重要。这只是整个问题的一小部分。 - Stephen York

Answer 2

我曾多次陷入这个困境，但我选择不使用工作流基础（Work Flow foundation）。以下是一些考虑因素（与您的类似）：

1. 涉及的工作流程要简单得多（由状态机和顺序动作组成），在WF中执行似乎会过度消耗精力。
2. 开发人员学习并有效使用WF的学习曲线比较高。使用状态转换表来描述有效的转换和采取的操作可以增加灵活性，开发人员对此感到舒适，易于理解概念和目的。
3. 业务流程变化的可能性很小，基本的变化可以轻松通过转换表进行。转换的变化意味着数据库脚本，而操作的变化则会导致新的发布/补丁。然而，这种情况发生的概率被认为很低。

经过13-14个月的回顾，我仍然认为不使用WF的决定是正确的。在我的看法中，WF只有在工作流程可能会更改和/或业务规则可能会更改的情况下才有意义。WF允许将工作流程隔离在单独的文件中，因此使得用户配置更加简单。

- VinayC

Answer 3

我们最近几个月一直在使用WF 4.0。我必须说，按照工作流的方式思考是挑战性的。然而，我可以告诉你它是值得的。我们一开始对此知之甚少。我们购买了一本初学者和专业书籍来了解WF 4.0。我自己看了很多在线视频，并关注了PDC 2009的最新消息，了解WF 4.0与先前版本有何不同，前者显得更好些。 我们需要提出一种解决方案，以应对工作流中的输入/输出参数，而无需将自定义活动限制在某些数据类型上，并且如何在活动之间传递参数。我已经想出了一个很好的解决方案，到目前为止，我们的工作流体验还不错。实际上，我们有一个工作流密集型应用程序，它变得越来越大，我真的无法想象自己在另一种环境中去解决它。我喜欢它具有的视觉效果：它让我远离if/else等构造的细节，使业务规则以一种不需要深入代码行就能明确发现的方式呈现，也不再需要钻研代码来了解正在发生什么或如何修复某个错误。 顺便说一下，我们所做的项目与你描述的非常相似，是一个中等规模的项目。 从我的话中可以看出，我喜欢它，并推荐尝试，尽管它存在一些风险，因为它是新技术，你必须想出一些创新的想法。 我的个人意见...

- Derar

---

我很感兴趣听听您处理活动间参数传递的解决方案。我一直在摸索 WF，但这是一个看起来有点棘手的领域，可能只是因为我缺乏理解。 - Chris Taylor

我认为这是他们需要更多工作的地方。无论如何，我们使用一个大的“全局哈希表”仓库，在其中添加已转换类型的变量。这些变量的命名约定包括它们的类型、名称和它们的父活动。这真的帮助了我们的实现。我意识到可能有更好的方法来做到这一点，但这个方法运行得非常好，并且在设计工作流程时可以以不同的方式利用它。例如，GerCustomer活动可能有少量的输入参数和2个输出参数：GetCustomer.str_customerID和GetCustomer.int_premium。希望这可以帮助到你。 - Derar

Answer 4

我认为今天谈论WF4中的工作流作为这种问题的技术选择并没有什么意义。正如Ladislav Mrnka所提到的，真正适合的是托管在AppFabric中的WCF WF服务。 我的经验是，这会带来巨大的回报，并且非常愉快，但一开始会出现问题，因为很多程序员没有正确理解这对他们来说更像是一种方法学转变而不是技术转变。另一方面，广泛涉猎和具有问题解决思维方式的人将WCF WF AppFabric视为一系列激动人心的机会。因此，如果项目团队的混合人员相当保守，是那些依赖于日常OO和模式集的C#开发人员，那么引入将会很难。如果团队更具创新性，则采用将容易得多，因为每个发现都会增加潜力和新的门户。 程序员在转移到这项技术时遇到的两个主要概念问题是： a)消息相关性和消息交换模式 b)工作流和单元测试 例如，在C#标准系统中，工作流很少是明确的，因此很少进行单元测试。整个工作流留给验收场景或集成测试。引入一个明确的WF作为软件工件，突然间标准开发人员想尝试并进行单元测试，这通常是不值得做的。 它的消息相关性方面对于那些不熟悉消息交换模式的人来说可能有点思维方式上的转变。大多数开发人员处理过进程内和远程调用、Web服务和SOAP，并且通常专注于其中一两个。抽象出所有这些并使用通用基于消息的系统可以在一开始时令人困惑。 但从积极的一面来看，最终结果是节省了很多时间并创造了很多机会。一个主要的事情是，如果工作流程在视觉上清晰，那么最终用户、开发人员和分析师可以一起处理它，消除开发生命周期中的不必要步骤，并将各方聚焦在一个工件上。此外，它通过鼓励每个业务域的WF套件来阻止专用应用程序中的功能岛和专用粘合层。此外，借助AppFabric，为您完成了持久性、日志记录和唤醒计划活动的管道。WF4的性能也非常出色。 我的建议是找到最具创新性或探索性的团队成员进行初步勘察，发现棘手的部分，使核心功能正常工作，并让该初始人员负责隔离剩余的工作。

- Sentinel

Answer 5

我在WF 3.5中完成了三个项目，我必须说这并不容易。它迫使你以全新的方式思考，特别是在使用持久性时。更新包含数百个未完成持续工作流的应用程序具有挑战性。序列化中的单个破坏性更改会导致所有工作流崩溃。引入多个版本的相同库以支持新旧运行的工作流是很常见的。这是具有挑战性的。 我还没有尝试过WF 4.0，但根据从BizTalk和WF 3.5中的经验来看，我认为它会类似。 无论如何，您可以采取的最佳方法是进行概念验证。从您的需求中选择一个工作流，并尝试在WF 4.0中实现它。您将花费一些时间，但您将证明是否能够在WF 4.0中实现它以及是否存在任何可见的好处。 如果您决定使用WF 4.0，我坚持要求您检查将WF作为WCF服务在Windows AppFabric中托管的可能性。AppFabric提供了一些开箱即用的功能来托管WF。

- Ladislav Mrnka

---

当我在考虑在我的应用程序中使用WF作为状态引擎时，持久化的问题一直困扰着我。对于各种原因，包括版本控制，每个开放案例都需要序列化WF的想法非常可怕。所以我的想法是，每当触发事件发生时，取出业务实体，创建新的工作流并将该实体附加到该工作流中，然后工作流会根据设计的状态机进行工作。完成后，抛弃工作流并将脏业务实体保存回数据库。但最后，我当然决定不使用WF。 - VinayC

我完全忘记了版本控制 - 这一点就足以成为不使用它的充分理由。 - Kane

@Kane，那并不一定是真的。你总是可以将状态外置。因此，你不必"反序列化工作流然后恢复它"，而是创建一个工作流实例，附加外部状态并运行工作流。这可以消除序列化和版本控制工作流的需要。 - VinayC

你好VinayC，你有这个东西的简单示例吗？“你将创建一个工作流实例，附加外部状态，然后运行工作流”，这听起来很像我想要进行PoC的东西，但我不太了解WF4，无法尝试这样的状态机，请帮忙。 - Jportelas

Answer 6

为了实现任何涉及角色和"子任务"的复杂保险理赔系统，您真正需要的是BPM（业务流程管理）解决方案，而不仅仅是工作流。Workflow Foundation 4.0非常流畅，但它确实无法接近BPM产品的功能性。 像Metastorm BPM、Global360和K2.NET这样的BPM解决方案提供了人为中心的工作流、任务、角色和系统集成，可以对业务流程进行建模和优化，如您的保险理赔系统。使用ASP.NET构建与BPM工作流引擎集成的界面，因为它们内置的设计器通常是有限的，并迫使您使用它们自定义的Web控件，通常不像ASP.NET Web控件那样功能齐全。

- Stephen Cao

---

使用自定义活动的 WF 4.0 怎么样？ - John Saunders

我尊重地不同意。K2确实为WF增加了一层功能（如授权、锁定和报告），但有经验的团队可以开发这些功能。WF 4带来了很多优点。BPM解决方案往往昂贵且“企业化”。 - TrueWill

Answer 7

使用团队已经熟悉并且感觉舒适的技术。Workflow Foundation不是一个可以直接使用的产品 - 它更像是一组可以嵌入应用程序中以构建工作流系统的组件。在我看来，工作流程逻辑是技术中最不重要的部分，首先你必须集中精力在GUI上，因为业务所有者只会关注GUI。但如果您的系统成功了，那么您必须准备好面对无休止的变更请求和新需求，因此您必须实现业务逻辑，使其易于更改并易于分成不同的过程以适应不同的用户需求（有时相互矛盾）。BPM有助于完成这项任务，因为它允许您拥有适合各种业务需求的单独多个版本的业务流程。您不需要完整的BPM引擎，但将业务逻辑编码为可进行版本控制并分成单独的业务流程非常有用 - 最糟糕的情况是处理“一切”且没有人能够理解的难以维护和交织在一起的代码块。有许多想法可以实现这一点 - 状态机、DSL（领域特定语言）、脚本等 - 您可以决定实现方式。但您应该始终从业务流程的角度思考并相应地组织您的逻辑，以反映这些流程。并且要准备好许多业务逻辑和数据结构的共存 - 这是我认为最困难的设计任务。

- nightwatch

Answer 8

我现在的情况是必须使用4.0，因为我们的生产环境还没有通过使用.NET 4.5的认证。我曾经花费了很大的精力来理解如何使长时间运行的工作流程适应我们的业务需求，但最终找到了一个优雅的解决方案。这不是任何人都可以轻松掌握的东西，因为需要考虑的事情太多了，但我确实相信WF是管理工作流状态的有力工具。 然而，我对WF 4.0有一个大问题，就是Maurice的评论： “基本原则是永远不要更改现有的工作流程，而是创建一个新的。” 如果你只想要一个新版本，那么这很好，但是如果你有50,000个持久化的工作流程，并且在某个时候意识到工作流程中存在错误怎么办？你需要能够更新xamlx并仍然与现有实例耦合。我尝试过在SQL Server实例表中解压缩各种元数据列，以查找将实例与工作流定义联系起来的内容，但没有成功。 我编写了一个同步应用程序，用于将旧系统中的数据导入到我们的新WF 4.0驱动系统中。我们基本上将数据加载到系统中，然后运行该进程，该进程会自动调用工作流步骤并调用验证方法，从而模拟用户交互。这只在我们实现的访问工作流服务主机的架构方面效果很好。这很适合一次性使用，在运行后，您可以进行检查以确保数据迁移过程的一致性，但是在系统上线后需要使用这种方法来处理数十万个案例并不是一种鼓舞人心的方法，反而会使集成简单错误修复的过程变得繁琐。 我的建议是，如果您的环境支持，请完全避免使用WF 4.0，直接使用4.5。它提供了动态更新和并行版本控制，可满足故障修复和WF版本控制的所有需求。由于我们的客户仍未通过使用4.5的认证，因此我仍然没有完全调查清楚如何使用它，但我非常期待这个机会。 我真的希望我们的客户不要要求更改策略（因此需要进行工作流调整），并且当前的工作流程没有任何错误。后者是一个徒劳和空洞的希望，因为错误总是会出现。 我真的无法理解WF开发团队发布一个系统的想法，其中开箱即用的东西无法轻松修复错误。他们应该开发一种重新绑定实例到新xamlx的技术。

- Stephen York