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

我负责一个开发人员团队，他们将要开始开发轻型保险理赔系统。该系统涉及许多手动任务和业务工作流，我们正在研究使用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，还是有替代技术（例如，简单状态机等）使用甚至更好的工作流引擎？

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

从您对业务问题的描述来看，WF4听起来很合适，所以那里没有问题。

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

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

那我对你有什么建议？不要对未知且未经验证的技术大肆赌博。使用WF4做一个小的，非关键的应用程序。这样，如果可以工作，则可以对其进行扩展，但是如果失败，则可以将其删除，并用更传统的.NET代码替换。这样，您将获得WF4的真实经验，而不必基于二手信息做出决定，并且您可以在此过程中学习到一种强大的新技术。如果可能的话，上一门WF4课程，因为这样可以节省您大量的时间来加快速度（这里是无耻的自我插入）。

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

我已经两次遇到这个难题，我选择不使用Work Flow Foundation。一些注意事项（与您类似）是

1. 所涉及的工作流程要简单得多（状态机和顺序动作的组合），而在WF中执行此工作似乎对于所涉及的工作而言是多余的。
2. 开发人员理解和有效使用WF的学习曲线被认为很高。状态转换表描述了有效的转换和要采取的措施，以提高灵活性，并且开发人员对此感到满意，可以轻松理解其概念和目的。
3. 业务流程更改的可能性很小，借助过渡表可以轻松进行基本更改。过渡更改将意味着数据库脚本，而操作更改将导致新的发行版/补丁程序。但是，这种发生的可能性被认为是低的。

回顾13-14个月后，我仍然认为不使用WF的决定是正确的。IMO，WF在很有可能改变工作流程和/或改变业务规则的地方有意义。WF允许将工作流隔离在单独的文件中，因此使用户可以对其进行配置将更加简单。

最近几个月我们一直在使用WF 4.0。我不得不说，思考工作流程方式是一项挑战。但是，我可以告诉您这是值得的。我们刚开始时了解的很少。我们已经购买了WF 4.0的初学者和专业书籍，对本书有所帮助。我本人在网上观看了许多视频，并在PDC 2009上关注了WF 4.0的最新消息以及它与以前有些令人讨厌的版本的不同之处。我们必须提出一个解决方案的主要事情是，在不将自定义活动绑定到某些数据类型以及如何在活动之间传递参数的情况下，如何在工作流中处理In /我们的参数。我为此提出了一个很好的解决方案，到目前为止，我们的工作流程经验还算不错。其实，我们有一个工作流程密集型应用程序，并且这个应用程序越来越大，我真的无法想象自己会在不同的环境中解决它。我喜欢它的视觉效果：它使我远离if / else等构造的细节，并使业务规则清晰可见，而不会强迫您深入代码行以了解发生了什么事情或如何修复一些错误。顺便说一下，我们从事的项目与您描述的非常相似，并且是一个中等规模的项目。您可以用我的话说出我喜欢它，我还是推荐它，尽管它是一项新技术，但存在一些风险，因此您必须提出一些创新想法。它使我远离if / else etc构造的细节，并使业务规则显而易见，而不会使您被迫深入代码行以了解正在发生的事情或如何解决一些错误。顺便说一下，我们从事的项目与您描述的非常相似，并且是一个中等规模的项目。您可以用我的话说出我喜欢它，我还是推荐它，尽管它是一项新技术，但存在一些风险，因此您必须提出一些创新想法。它使我远离if / else etc构造的细节，并使业务规则显而易见，而不会使您被迫深入代码行以了解正在发生的事情或如何解决一些错误。顺便说一下，我们从事的项目与您描述的非常相似，并且是一个中等规模的项目。您可以用我的话说出我喜欢它，我还是推荐它，尽管它是一项新技术，但存在一些风险，因此您必须提出一些创新想法。

我的2美分

我在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。

我认为今天谈论WF4中的工作流作为解决此类问题的技术选择并没有多大意义。正如上面的Ladislav Mrnka所述，真正合适的是由AppFabric托管的WCF WF Services。

我的经验是，它带来了可观的收益，并且非常令人愉快，但是一开始就出现了问题，因为对于许多程序员而言，人们没有适当地意识到，这是方法论的转变，而不是技术的转变。另一方面，通才和具有解决问题思路的人将WCF WF AppFabric视为一系列令人兴奋的机会。因此，如果项目中的人员是相当保守的C＃开发人员，他们每天都在他们的OO和模式中附加这些内容，那么将很难引入。如果团队更具创新能力，那么采用该技术将容易得多，因为每次发现都会增加潜在的机会和新的机会。

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

对于不熟悉消息交换模式的人来说，它的消息相关性方面有点心态转变。大多数开发人员都处理过流程和远程调用，Web服务和SOAP，通常专注于其中的一两个。首先，要对其进行抽象并与基于通用消息的系统一起工作可能会令人困惑。

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

我的建议是找到最具创新性或探索性的团队成员进行初始侦查，以发现棘手的部分，使核心功能正常工作，并由最初的人员负责，然后将其余工作区分开。

为了建立涉及角色和“子任务”的任何复杂性的保险索赔系统，您确实需要BPM解决方案，而不仅仅是工作流程。Workflow Foundation 4.0很漂亮，但实际上并不能与BPM产品的功能相提并论。

BPM解决方案（例如Metastorm BPM，Global360和K2.NET）提供了以人为中心的工作流程，任务，角色和系统集成，可以对保险索赔系统等业务流程进行建模和简化。使用ASP.NET构建与BPM工作流引擎集成的界面，因为其内置设计器通常受到限制，并迫使您使用其自定义构建的Web控件，这些控件通常不具备ASP.NET Web控件的全部功能。

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

我处于必须使用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的技术。