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

Question

我负责一群即将开始开发轻量级保险索赔系统的开发人员。该系统涉及许多手动任务和业务工作流程，我们正在寻找使用Windows Workflow（.NET 4.0）。

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

1. 检查客户是否存在欺诈行为 - 操作员致电各信用公司以检查和评估欺诈客户的潜力的手动流程。从这里，子任务可以输入多个子状态（检查进度，参考检查失败，通过参考检查等）
2. 将物品发送到维修中心 - 手动过程中，保单持有人提出索赔的物品将被送到维修中心进行修理。从这里，子任务可以输入许多子状态（等待修复，进行中，修复，发布等）。 只有在每个子任务的状态达到预定义状态（基于业务规则）后，才能继续声明。

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

1. 技能组合 - 查看普通开发人员的技能组合，我看不到很多了解或了解工作流程的开发人员。
2. 可维护性 - 社区内对WF 4.0项目的支持似乎很少，而且缺乏技能组合引起了对可维护性的担忧。
3. 进入障碍 - 我感觉Windows Workflow的学习曲线陡峭，而且并不总是那么容易上手。
4. 新产品 - 由于Workflow已经完全重写为.NET 4.0，我将该产品视为第一代产品，可能没有必要的稳定性。
5. 声誉 - 以前版本的工作流程并不受欢迎，被认为难以开发并导致业务不佳。

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

Answer 1

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

从您对业务问题的描述来看，WF4听起来很不错，所以没有问题。

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

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

那么我对你的建议是什么？ 不要对未知的事情进行重大赌博，对于未经证实的技术而言。使用WF4做一个小的，非关键的应用程序。这样，如果它工作，你可以扩展它，但如果它失败你可以撕掉它，并用更传统的.NET代码替换它。通过这种方式，您可以获得WF4的真实体验，而无需根据二手信息做出决策，并在此过程中学习一种新的强大技术。如果可能的话，参加WF4课程，因为这样可以节省大量的时间来加快速度（无耻的自我插件here）。

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

Answer 2

我几次遇到这种困境，我选择不使用Work Flow基础。一些注意事项（与您的相似）是

1. 所涉及的工作流程更简单（状态机和顺序操作的组合），并且在WF中执行它似乎过度了解所涉及的工作。
2. 开发人员有效理解和使用WF的学习曲线被认为很高。描述有效转换和要采取的操作的状态转换表用于提供额外的灵活性，开发人员对此感到满意，易于理解概念和目的。
3. 业务流程变化的机会很小，在过渡表的帮助下很容易实现基本的变化。转换中的更改将意味着数据库脚本，而操作中的更改将导致新的发布/修补程序。但是，这种情况发生的可能性被认为很低。

回顾13-14个月之后，我仍然认为不使用WF的决定是正确的。 IMO，WF在工作流程可能发生变化和/或业务规则可能发生变化的可能性很大的情况下是有意义的。 WF允许在单独的文件中隔离工作流，因此使用户可以配置它将更简单。

Answer 3

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

我的2美分......

Answer 4

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

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

无论如何，你可以采取的最佳方法是做概念验证。从您的要求中获取单个WF并尝试在WF 4.0中实施。您将花费一些时间，但您将证明您是否能够在WF 4.0中做到这一点并且是否有任何明显的好处。

如果您决定使用WF 4.0，我坚持要求您检查将WF作为Windows AppFabric中托管的WCF服务运行的可能性。 AppFabric为托管WF提供了一些开箱即用的功能。

Answer 5

我认为今天谈论WF4中的Workflow作为此类问题的技术选择并不合理。如上面Ladislav Mrnka所述，真正合适的是在AppFabric中托管的WCF WF服务。

我对此的体验是它带来了巨大的收益并且非常愉快，但是问题在一开始就出现了，因为对于许多程序员而言，这是一种方法转变而不是技术转变，这一点并不适当。另一方面，通才和那些有解决问题心态的人将WCF WF AppFabric视为一系列令人兴奋的机会。因此，如果项目中人员的混合是相当保守的C＃开发人员附加到他们的日常OO和模式集，那将很难介绍。如果团队更具创新性，那么采用将变得更加容易，因为潜在的和新的门廊随着每次发现而增加。

程序员转向这项技术的两个主要概念问题是： a）消息关联和消息交换模式 b）工作流程和单元测试 例如，在C＃的标准系统中，工作流很少是明确的，因此很少进行单元测试。整个工作流程留待接受方案或集成进行测试。将明确的WF作为软件工件引入，突然标准开发人员想要尝试对其进行单元测试，这通常不值得。

对于那些不熟悉消息交换模式的人来说，它的消息相关性方面有点心态转变。大多数开发人员都处理过程和远程调用，Web服务和SOAP，并且通常关注其中的一个或两个。要在所有内容之上进行抽象并使用基于消息的通用系统，最初可能会令人困惑。

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

我的建议是找到最具创新性或探索性的团队成员进行初步侦察，以发现棘手的部分，让核心功能发挥作用，让初始人负责将剩余的工作分开。

Answer 6

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

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

Answer 7

使用您的团队所熟知并熟悉的技术。 Workflow Foundation不是一种可以立即使用的产品 - 它可以嵌入您的应用程序中，以构建工作流程系统。恕我直言，工作流逻辑是最不重要的技术，首先你必须专注于GUI，因为企业主除了GUI之外什么都看不到。但是，如果您的系统成功，那么您必须为无休止的变更请求和新要求做好准备，因此您必须实现业务逻辑，以便易于更改并轻松划分为单独的流程以满足不同的用户需求（有时相互矛盾） 。 BPM有助于完成此任务，因为它允许您拥有适合各种业务需求的单独的多个业务流程版本。您不需要完全成熟的BPM引擎，但是对您的业务逻辑进行编码以便对其进行版本控制并将其划分为单独的业务流程非常有用 - 最糟糕的事情是处理“一切”的不可更新和交织的代码块并且没有人能够理解。有很多想法 - 状态机，DSL（领域特定语言），脚本等 - 您决定实现应该是什么。但是，您应该始终考虑业务流程并相应地组织您的逻辑，以便它反映这些流程。 并为多种业务逻辑和数据结构的共存做好准备 - 这是最困难的设计任务。

Answer 8

我遇到的情况是我必须使用4.0，因为.NET 4.5还没有被认可用于我们的prod环境。我一般都非常了解如何让长时间运行的工作流程满足我们的业务需求，但最终找到了一个优雅的解决方案。这不是任何后来支持的人可以轻松拿起来的，因为需要考虑很多，但我确实相信WF是一种管理工作流状态的工具。

我对WF 4.0的一个重要问题是莫里斯的评论：

  

基本永远不会改变现有的工作流程，总是创建一个新工作流程

如果您只是想要一个新版本，那就太棒了，但是如果您有50,000个持久工作流并且在某个时候意识到工作流程中存在错误怎么办？您需要能够更新xamlx并仍然可以耦合到现有实例。我已经尝试对SQL Server实例表中的各种元数据列进行解压缩，以找到将实例与工作流定义联系起来而没有任何运气的东西。

我写了一个同步应用程序，用于将旧系统中的数据导入我们新的WF 4.0驱动的系统。我们基本上将数据加载到系统中，然后运行自动调用工作流程步骤并调用验证方法的过程，主要是模拟用户交互。由于我们为访问工作流服务主机而实现的体系结构，这才真正适用于我们。这是一个很好的一次性，在运行后你可以通过检查以确保数据迁移过程的一致性，但是一旦系统出现，必须使用这种方法可能成千上万的情况并不是真正的方法这会给整合过程带来信心和负担，简单的错误修复。

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

我迫切希望的是我们的客户不要求更改策略（以及工作流程调整），并且当前的工作流程没有任何错误。后者是一个虚荣和空洞的希望，因为总是会出现错误。

我真的无法理解WF开发团队的负责人发布了一个开箱即用的系统，你无法轻易修复bug。他们应该开发出一种将实例重新绑定到新xamlx的技术。

Answer 9

看起来你的团队是以c＃为中心的，所以也许我的想法不适用。我经营着一家拥有相当多员工的科技公司，我们遇到了同样的需求。与许多其他业务不同，我们有大量开发人员可供使用，因此基于代码的工作流解决方案非常理想。

问题是我们没有足够的资源来进行系统设置/维护和许可证成本，除非它对我们的业务来说是非常核心的。 Azure / Window工作流程是不可能的。我们还尝试了很多大型BPM套件，并遇到了更多问题：它们为您提供了相当紧张的可视化编程体验。编程只是无法在可视化环境中完成。你可以看到真正让我们感兴趣的list of non-BPM software。像Decisions.com和IFTTT这样的工具很整洁。事实上，Decisions可能非常适合您，因为它根据我的理解与Microsoft产品集成。

故事的结尾是我们将自己的软件作为创业冒险和内部使用。工作流程可以与任何API一起编写和集成，也可以直接与表单一起编写人工流程。例如，我们正在整合工作流程，以便为新开发人员提供大量其他软件。它非常环保，但在工作流场景中非常强大。您可以在这里结帐Nebri。由于基于规则的方法触发事件，因此架构完全不同。它减少了您必须编写的代码量，并且具有速度权衡。但它可以很容易地处理像complex-event-processing这样的事情，因为Python可供您使用。