到工作流还是不到工作流？

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

An example of the business domain is as follows: 投保人致电联络中心提出索偿。这个“事件”触发两个子任务，这两个子任务是并行手动操作的，可能需要很长时间才能完成;

  1. 检查客户是否存在欺诈行为——一个手工过程，操作员通过这个过程打电话给各个信贷公司，检查和评估欺诈客户的潜力。从这里，子任务可以输入一些子状态(检查在进行中，失败的参考检查，通过参考检查等)
  2. 将物品送到维修中心-将投保人提出索赔的物品送到维修中心进行修理的人工过程。从这里子任务可以输入一些子状态(等待修复，进行中，修复，发布等)。 The claim can only proceed once the status of each sub task has reached a predefined status (based on the business rules).

从表面上看，工作流确实是最好的技术选择; 然而，在使用 WF 4.0时，我确实有一些顾虑。

  1. 技能集-看看一般的开发人员技能集，我没有看到很多开发人员理解或了解工作流。
  2. 可维护性——在社区中似乎很少有人支持 WF 4.0项目，而且这种情况加上缺乏技能集引起了对可维护性的关注。
  3. 进入障碍-我有一种感觉，Windows 工作流有一个陡峭的学习曲线，它并不总是那么容易拿起。
  4. 新产品-作为工作流已经完全重写。NET 4.0我认为该产品是第一代产品，可能没有必要的稳定性。
  5. 声誉-以前版本的工作流没有得到很好的接受，被认为难以开发，并导致业务吸收能力差。

因此，我的问题是，我们应该使用 Windows Workflow (WF)4.0来解决这种情况，还是有其他替代技术(例如，简单状态机等) ，甚至是更好的工作流引擎来使用？

26502 次浏览
小开

我已经遇到过几次这样的困境，我选择不使用工作流基础。一些考虑(类似于你的考虑)是

  1. 涉及的工作流程要简单得多(结合了国家机器和顺序行动) ，而且在 WF 这样做似乎对所涉及的努力有些过头。
  2. 开发人员理解和有效使用 WF 的学习曲线被认为是很高的。状态转换表描述了有效的转换和要采取的行动，用于增加灵活性，开发人员对此感到舒适，很容易理解概念和目的。
  3. 业务流程变更的机会微乎其微，借助于转换表，很容易实现基本的变更。转换的改变意味着数据库脚本，而操作的改变将导致新的发布/补丁。然而，这种情况发生的可能性被认为是低的。

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

小开

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

我还没有尝试过 WF 4.0，但是基于 BizTalk 和 WF 3.5的经验，我认为它会很相似。

无论如何，你能采取的最好的方法是做概念验证。从您的需求中提取单个 WF，并尝试在 WF 4.0中实现它。您将花费一些时间与它，但你将证明，如果你能够做到这一点，在 WF 4.0和如果有任何可见的好处。

If you decide to use WF 4.0 I insist that you check possibility to run WF as WCF service hosted in Windows AppFabric. AppFabric provides some out of the box functionality for hosting WFs.

小开
最佳答案

我已经做了几个 WF4项目，所以让我们看看，如果我可以添加任何有用的信息，其他的答案。

从您的业务问题的描述，它听起来像 WF4是一个很好的匹配，所以没有问题。

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

在执行这些长时间运行的工作流类型时，大多数时候使用驻留在 IIS/WAS 中的工作流服务是最佳途径。这使得解决版本控制问题也不难，只需让第一条消息返回工作流版本，并将其作为后续消息的一部分。接下来，将 WCF 路由器放在两者之间，根据版本将消息路由到正确的端点。基本的做法是永远不要改变现有的工作流程，而是创建一个新的工作流程。

那我给你的建议是什么？ 不要在一个未知的，对你来说未经证实的，技术上大赌一把。使用 WF4完成应用程序的一个小的、非关键的部分。这样，如果它工作，你可以扩大它，但如果它失败了，你可以撕掉它，取而代之的是更传统的。NET 代码。通过这种方式，您可以获得使用 WF4的实际经验，而不必根据二手信息做出决定，并且在此过程中学习一种新的强大技术。如果可能的话，参加 WF4的课程，因为这将节省你很多时间，以获得更快的速度(无耻的自我插入 给你)。

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

小开

过去几个月我们一直在使用 WF 4.0。我不得不说，以工作流的方式思考是一种挑战。但是，我可以告诉你，这是值得的。刚开始的时候我们知道的很少。我们已经为 WF 4.0购买了一本初学者和专业书籍，这对我们很有帮助。我自己在网上看了很多视频，关注了 PDC 2009关于 WF 4.0的突发新闻，以及它与之前那些有点糟糕的版本的不同之处。 我们必须提出解决方案的一个主要问题是，我们可以在工作流中处理 In/Our Arguments，而不必将自定义活动绑定到某些数据类型，以及如何在活动之间传递参数。我已经想出了一个很好的解决方案，到目前为止，我们的工作流体验一点也不差。实际上，我们有一个工作流密集型的应用程序，它正变得越来越大，我真的无法想象自己在不同的环境中解决它。我喜欢它的视觉效果: 它让我远离 if/else 等结构的细节，并且让业务规则显而易见，不会让你不得不深入到代码行中去了解发生了什么或者如何修复一些 bug。 顺便说一下，我们工作的项目和你描述的非常相似，是一个中等规模的项目。 你可以从我的话说，我喜欢它，我确实推荐它，虽然它包含了一些风险，因为它是一项新技术，你必须拿出一些创新的想法。

我的意见是..。

小开

为了完成任何复杂的涉及角色和“子任务”的保险索赔系统，您确实需要一个 BPM 解决方案，而不仅仅是工作流。Workflow Foundation 4.0非常流畅，但它的功能与 BPM 产品的功能并不相近。

像 Metastorm BPM、 Global360和 K2.NET 这样的 BPM 解决方案提供了以人为中心的工作流、任务、角色和系统集成，可以对业务流程(如保险索赔系统)进行建模和简化。使用 ASP.NET 来构建与 BPM 工作流引擎集成的界面，因为它们的内置设计器通常是有限的，并迫使你使用他们自定义构建的 Web 控件，这些控件通常不像 ASP.NET Web 控件那样功能齐全。

小开

我认为在今天讨论 WF4中的工作流作为这类问题的技术选择是没有意义的。正如上面 Ladislav Mrnka 提到的，真正合适的是在 AppFabric 中托管的 WCF WF 服务。

我的经验是，这样做可以带来巨大的回报，而且非常令人愉快，但问题在开始时就出现了，因为对于许多程序员来说，这是一种方法上的转变，而不是技术上的转变，这一点没有得到正确的认识。另一方面，多面手和那些具有解决问题思维的人将 WCF WF AppFabric 视为一系列令人兴奋的机会。因此，如果项目中的人员组合是相当保守的 C # 开发人员，并且与他们的日常面向对象和模式集相关，那么就很难介绍。如果团队更具创新性，那么采用就会容易得多，因为潜在的和新的入口会随着每个发现而成倍增加。

程序员在使用这种技术时遇到的两个主要概念性问题是: A)消息相关性和消息交换模式 B)工作流程及单元测试 例如，在 C # 的标准系统中，工作流很少是显式的，因此很少进行单元测试。整个工作流由验收场景或集成进行测试。引入一个明确的 WF 作为软件工件，然后标准开发人员突然想要尝试和单元测试它，这通常是不值得做的。

对于那些不熟悉消息交换模式的人来说，它的消息相关性方面是一种思维模式的转变。大多数开发人员都处理过进程和远程调用、 Web 服务和 SOAP，并且通常关注其中的一两个。首先，将它们抽象化并使用基于消息的通用系统可能会让人感到困惑。

从积极的方面来看，最终的结果是节省了大量的时间，创造了大量的机会。一个主要的问题是，如果工作流在视觉上是清晰的，那么最终用户、开发人员和分析人员就可以一起工作，消除开发生命周期中不必要的步骤，并将各方集中在一个工件上。此外，它通过鼓励在每个业务域中使用 WF 中的一套业务流程来阻止专用应用程序中的功能孤岛，这些应用程序具有专用的粘合层。此外，通过 AppFabric，持久化、日志记录和唤醒计划活动的管道工作都可以为您完成。WF4的性能也很出色。

My recommendation would be to find the most innovative or explorative team member do the initial scouting to discover the tricky parts, get the core functions working, and have that initial person be responsible for then compartmentalising the remaining work.

小开

使用您的团队熟悉并且感觉舒适的技术。Workflow Foundation 不是一个可以直接使用的产品，而是一组可以嵌入到应用程序中以构建工作流系统的部件。恕我直言，工作流逻辑是技术中最不重要的一部分，首先你必须专注于 GUI，因为业务所有者除了 GUI 什么也看不到。但是，如果你的系统是成功的，那么你必须准备永无止境的更改请求和新的需求，所以你必须实现你的业务逻辑，以便易于更改和容易划分为不同的过程，以适应不同的用户需求(有时相互矛盾)。BPM 有助于完成这项任务，因为它允许您拥有适合不同业务需求的独立的、多个版本的业务流程。你不需要完全成熟的 BPM 引擎，但是编写业务逻辑代码是非常有用的，这样它就可以被版本化并划分为单独的业务流程——最糟糕的事情就是拥有一个不可维护的、错综复杂的代码块，它可以处理“所有事情”，而且没有人能够理解。关于这一点有很多想法——状态机、 DSL (领域特定语言)、脚本等等——你决定应该实现什么。但是您应该始终从业务流程的角度思考问题，并相应地组织您的逻辑，以便反映这些流程。 并准备好多种业务逻辑和数据结构的共存——这是最困难的设计任务。

小开

我现在的情况是，我必须使用4.0作为。NET 4.5还没有被认可在我们的产品环境中使用。对于如何让长时间运行的工作流程适合我们的业务需求，我有着非常痛苦的理解，但最终找到了一个优雅的解决方案。它不是任何后来支持的人都可以轻松获得的东西，因为有太多东西需要考虑，但我确实相信 WF 是管理工作流状态的工具。

不过，我对 WF 4.0有一个很大的不满，那就是莫里斯的评论:

基本的做法是永远不要改变现有的工作流程，而是创建一个新的工作流程

如果您只想要一个新版本，那么这很好，但是如果您有50,000个持久化的工作流，并且在某个时候意识到工作流中存在 bug，那么该怎么办呢？您需要能够更新 xamlx 并仍然与现有的实例耦合。我曾尝试解压缩 SQLServer 实例表中的各种元数据列，以找到将实例与工作流定义联系起来的内容，但没有找到。

我确实编写了一个同步应用程序，用于将旧系统中的数据导入到新的 WF 4.0驱动系统中。我们基本上把数据加载到系统中，然后运行这个过程，自动调用工作流步骤和调用验证方法，实质上是模仿用户交互。由于我们实现了用于访问工作流服务主机的体系结构，所以这种方法在我们身上真的很有效。这是一次性的，在运行之后你可以通过检查来确保数据迁移过程的一致性，但是一旦一个系统启动，不得不使用这种方法来处理成千上万的情况，这并不是一个真正的方法来灌输信心和加重集成过程的负担简单的 bug 修复。

我的建议是完全避免使用 WF 4.0，如果环境支持的话，直接使用4.5。动态更新和并行版本控制，它提供了错误修复和 WF 版本控制所有开箱即用。我还没有调查到底为什么4.5仍然没有被我们的客户认可使用，但是急切地等待着这个机会。

我非常希望我们的客户不会要求对策略进行更改(因此也不会要求对工作流进行调整) ，并且当前的工作流不会出现任何错误。后者是一个徒劳和空洞的希望，因为臭虫总是弹出。

I really can't understand what was going through the WF dev team's heads to release a system where out of the box you can't fix bugs easily. They should have developed a technique for re-binding an instance to new xamlx.


提交答案