工作stream程还是不工作stream程？
我负责一个开发团队，他们即将开始开发一个轻量级的保险索赔系统。 系统涉及大量手动任务和业务工作stream程，我们正在使用Windows Workflow（.NET 4.0）。
业务领域的一个例子如下：保单持有人呼叫联络中心提出索赔。 这个“事件”触发了两个并行手动操作的子任务，可能需要很长时间才能完成。
- 检查客户是否存在欺诈行为 – 手动程序，运营商通过呼叫各种信用卡公司来检查和评估欺诈客户的潜力。 从这里子任务可以input多个子状态（检查进行中，失败的参考检查，通过的参考检查等）
- 将项目发送到维修中心 – 保单持有人提出索赔的项目被送到维修中心进行修理的手动过程。 从这里子任务可以input许多子状态（等待修复，进行中，修复，发布等）。 只有在每个子任务的状态达到预定义状态（基于业务规则）后，才能继续执行索赔。
从表面上看，Workflow确实是最好的技术select; 不过我在使用WF 4.0时有一些担心。
- 技能集 – 查看平均开发人员技能集，我没有看到许多了解或了解工作stream程的开发人员。
- 可维护性 – WF 4.0项目在社区内似乎没有什么支持，加上缺乏技能，引起对可维护性的关注。
- 进入壁垒 – 我有一种感觉，Windows Workflow有一个陡峭的学习曲线，并不总是那么容易接受。
- 新产品 – 由于.NET 4.0已经完全重写了工作stream程，因此我将该产品视为第一代产品，可能没有必要的稳定性。
- 声誉 – 上述版本的工作stream程没有得到很好的接受，认为难以发展，导致业务不景气。
所以我的问题是我们应该使用Windows工作stream（WF）4.0这种情况下，还是有一个替代技术（IE， 简单的状态机等），甚至更好的工作stream引擎使用？
我已经做了几个WF4项目，所以让我看看是否可以添加任何有用的信息，以其他答案。
从你的业务问题的描述，这听起来像WF4是一个很好的匹配，所以没有问题。
关于你的担忧，你是对的。 基本上WF4是一个新产品，缺乏一些重要的function，并有一些粗糙的优势。 有一个学习曲线，你必须做一些不同的事情。 主要观点是长时间运行和序列化，这是一般开发人员不习惯的东西，需要一些思路才能正确，因为我常常听到人们在序列化entity framework数据上下文时遇到问题。
大多数情况下，使用IIS / WAS中托pipe的工作stream服务是执行这些长时间运行的工作stream程的最佳途径。 这使得解决版本控制问题也不难，只要第一条消息返回工作stream版本，并将其作为每个后续消息的一部分。 接下来将WCF路由器置于其间，根据版本将消息路由到正确的端点。 基本是永远不要改变现有的工作stream程，总是要创build一个新的工作stream程。
那么我有什么build议吗？ 不要对未知的事物进行大赌注，对于你未经证实的技术。 做一个小的，非关键的，使用WF4的应用程序。 这种方式，如果它的工作，你可以扩大它，但如果它失败，你可以撕掉它，并用更传统的.NET代码取代它。 这样，您就可以获得WF4的实际经验，而不必根据二手信息作出决定，并在此过程中学习一种新的强大的技术。 如果可能的话，参加一个WF4的课程，因为这将节省你很多时间在加快速度（无耻的自我插入）。
关于简单的状态机。 我没有使用它，但我的印象是短暂运行，在内存，状态机。 WF4的主要优点之一是运行时间长。
我几次来到这个困境，我select不使用工作stream基础。 一些考虑（类似于你的）是
- 涉及到的工作stream程比较简单（状态机和顺序操作的组合），并且在WF中执行操作看起来过于费力。
- 学习曲线让开发者理解和有效地使用WF被认为是很高的。 描述有效转换和要采取的行动的状态转换表被用于额外的灵活性，并且开发者对此感到满意，易于理解概念和目的。
- 转换表的帮助下，业务stream程变化的机会很渺茫，基本的变化很容易实现。 转换中的变化将意味着数据库脚本，而更改操作将导致新的发行版/补丁程序。 但是，这种情况的可能性被认为是低的。
回顾13-14个月后，我仍然认为不使用WF的决定是正确的。 国际海事组织，WF是有意义的，有很强的可能引起工作stream程可以改变和/或业务规则可能改变。 WF允许在单独的文件中隔离工作stream程，因此使用户可以configuration更简单。
过去几个月我们一直在使用WF 4.0。 我不得不说，考虑工作stream程的方式是一个挑战。 不过，我可以告诉你这是值得的。 我们开始的时候知道的很less。 我们已经为WF 4.0买了一本初学者和专业书籍。 我自己在网上观看了很多video，并在PDC 2009上看到了关于WF 4.0的突发新闻，以及它与之前的有些糟糕的版本有什么不同。 我们不得不提出解决scheme的一个主要问题就是我们如何处理工作stream中的In / Our Arguments，而不将自定义活动限制在某些数据types以及如何在活动之间传递参数。 我为此提出了一个很好的解决scheme，迄今为止我们的工作stream程经验并不差。 实际上，我们有一个工作stream程密集型应用程序越来越大，我真的无法想象自己在不同的环境中解决它。 我喜欢它所具有的视觉效果：它使我远离了if / else等构造的细节，并且使得业务规则显而易见，不会让你被迫深入代码行知道发生了什么或如何修复一些错误。 顺便说一下，我们所从事的项目与您所描述的非常相似，并且是一个中等规模的项目。 从我的文字中可以看出，我喜欢它，而且我推荐它，但是由于它是一种新技术，所以会带来一些风险，你必须提出一些创新的想法。
我的2分钱…
我在WF 3.5中做了三个项目，我不得不说这不容易。 它迫使你以全新的方式思考，特别是在使用持久性的时候。 更新包含数百个不完整的持续工作stream的应用程序是一个挑战。 单次更改序列化崩溃全部。 引入同一个库的多个版本以支持新旧运行的工作stream程是常见的。 这是有挑战性的。
我还没有尝试过WF 4.0，但基于从BizTalk和WF 3.5的经验，我认为这将是类似的。
无论如何，你可以采取的最好的方法是做概念validation。 从你的需求中获取单个WF，并试图用WF 4.0来实现。 你会花一些时间，但你会certificate，如果你能够做到这一点在WF 4.0，并有任何明显的好处。
如果您决定使用WF 4.0，我强烈build议您检查是否可以运行WF作为Windows AppFabric中托pipe的WCF服务。 AppFabric为托pipeWF提供了一些开箱即用的function。
我认为今天谈论WF4中的工作stream程作为这类问题的技术select并没有什么意义。 正如上面Ladislav Mrnka所提到的，真正合适的是由AppFabric托pipe的WCF WF Services。
我的经验是，分红是非常愉快的，但是一开始就出现了问题，因为对于许多程序员来说，这是一种方法转变，而不是技术转变。 另一方面，通才和那些有解决问题的人都认为WCF AppFabric是一个令人兴奋的机会。 所以，如果项目中的人员是相当保守的C＃开发人员，他们的日常OO和模式集合，这将是很难介绍。 如果团队更具创新性，那么采用将会更容易，因为潜在的和新的门户会随着每个发现而增加。
程序员转向这一技术的两个主要概念问题是：a）消息关联和消息交换模式b）工作stream和unit testing在C＃中的标准系统中，例如工作stream很less显式，因此很less进行unit testing。 整个工作stream程由验收场景或集成进行testing。 引入一个明确的WF作为一个软件神器，突然标准的开发者想要尝试和unit testing，这通常是不值得的。
对于那些不熟悉消息交换模式的人来说，它的消息关联方面有点心态上的转变。 大多数开发者已经在处理和远程调用，Web服务和SOAP，并且通常集中在其中的一个或两个。 如果要抽象以上所有的内容，首先使用一个基于通用消息的系统可能会造成混淆。
从积极的方面来看，最终的结果是节省了大量时间，并创造了很多机会。 一个主要的问题是，如果视觉上很清晰，那么最终用户，开发人员和分析师可以一起工作，消除开发生命周期中不必要的步骤，并将各方聚焦在一个工件上。 此外，它鼓励在每个业务领域中使用WF的一套业务stream程，从而阻止专用应用程序中的function孤岛，以及专用的粘合层。 此外，通过AppFabric，持久性，日志logging和唤醒计划活动的工作都将为您完成。 WF4的performance也很出色。
我的build议是find最具创新性或探索性的团队成员进行初步的探索，发现棘手的部分，使核心function发挥作用，让最初的人负责把剩下的工作划分出来。
为了做一个涉及angular色和“子任务”的任何复杂的保险索赔系统，你真的需要一个BPM解决scheme，而不仅仅是工作stream程。 工作stream基础4.0是光滑的，但它确实不能接近BPM产品的function。
BPM解决scheme（如Metastorm BPM，Global360和K2.NET）提供了以人为中心的工作stream程，任务，angular色和系统集成，可以模拟和简化业务stream程，如保险索赔系统。 使用ASP.NET构build与BPM工作stream引擎集成的界面，因为其内置的devise人员通常是有限的，并迫使您使用自定义构build的Web控件，这些控件通常不像ASP.NET Web控件那样全function。
与您的团队知道和感觉舒适的技术。 Workflow Foundation不是一个可以直接使用的产品，而是一系列可以embedded到应用程序中以构build工作stream系统的组件。 恕我直言，工作stream程逻辑是最不重要的一部分技术，首先你必须专注于GUI，因为企业主不会看到任何东西，但GUI。 但是，如果你的系统是成功的，那么你必须为变化的要求和新的需求做好准备，所以你必须实现你的业务逻辑，这样很容易改变和容易分成不同的过程以适应不同的用户需求（有时是矛盾的） 。 BPM有助于完成此任务，因为它使您可以拥有适合各种业务需求的单独的多个业务stream程版本。 您不需要完整的BPM引擎，但是对您的业务逻辑进行编码是很有用的，这样可以对其进行版本pipe理，并将其划分为单独的业务stream程 – 最糟糕的情况就是处理“一切”的无法维系的代码块，没有人能理解。 有很多想法 – 状态机，DSL（域特定语言），脚本等 – 您决定实施应该是什么。 但是，你应该总是考虑业务stream程，并相应地组织你的逻辑，以反映这些过程。 并准备好许多业务逻辑和数据结构变体的共存 – 这是最困难的devise任务恕我直言。
看起来你的团队是以c＃为中心的，所以也许我的想法不适用。 我和一些员工经营一家科技公司，遇到了同样的需要。 与许多其他业务不同，我们拥有大量开发人员，因此基于代码的工作stream程解决scheme非常理想。
问题是我们没有足够的资源来进行系统设置/维护和许可成本，除非它是我们业务的核心。 Azure / Window Workflow是不可能的。 我们也尝试了很多大型BPM套件，并且遇到了更多的问题：它们为您提供了一个相当逼真的可视化编程体验。 编程不能完全在视觉环境中完成。 您可以看到实际上对我们感兴趣的非BPM软件列表 。 像Decisions.com和IFTTT这样的工具是整洁的。 事实上，Decisions可能是一个很好的select，因为据我了解，它可以与Microsoft产品集成。
故事的结尾是我们将自己的软件作为一种创业冒险，并用于内部使用。 可以将工作stream程编写并与任何API集成，也可以直接使用表单进行人员stream程。 例如，我们正在整合新的开发人员的工作stream程，以吸引/更新大量的其他软件。 这是相当绿色，但在工作stream程场景非常强大。 你可以在这里结帐Nebri 。 由于基于规则的方法引发事件，所以架构是完全不同的。 它减less了你必须编写的代码量，并且有一个速度的折衷。 但是它可以轻松处理复杂事件处理等事情，因为Python可供您使用。
我处于一个我不得不使用4.0的情况，因为.NET 4.5没有被认可用于我们的产品环境。 我对于如何让长时间运行的工作stream程适合我们的业务需求有了很大的理解，但最终却find了一个优雅的解决scheme。 这不仅仅是任何后来支持的人都可以轻松地拿起来，因为有太多需要思考的东西，但是我相信WF是一个pipe理工作stream状态的工具。
我对WF 4.0的一个大问题是Maurice的评论：
基本是永远不要改变现有的工作stream程，总是要创build一个新的工作stream程
如果你只是想要一个新的版本，这是非常好的，但是如果你有5万个持久化的工作stream程，并且在某个时候意识到工作stream程中存在一个错误呢？ 您需要能够更新xamlx并仍然耦合到现有的实例。 我已经试过在SQL Server实例表中对各种元数据列进行解压缩，以find将实例与工作stream定义联系起来的东西，而没有任何运气。
我编写了一个同步应用程序，用于从旧系统导入数据到新的WF 4.0驱动的数据中。 我们基本上把数据加载到系统中，然后运行一个自动调用工作stream步骤和调用validation方法的过程，实质上是嘲笑用户交互。 由于我们实现访问工作stream服务主机的体系结构，这只能与我们合作得很好。 作为一个很好的方法，在运行之后，您可以通过检查来确保数据迁移过程的一致性，但是一旦系统处于活动状态，必须将这种方法用于潜在的成千上万的情况并不是真正的方法灌输信心和负担整合简单错误修复的过程。
我的build议是，你完全避免使用WF4.0，如果你的环境支持，直接使用4.5。 dynamic更新和并排版本，它提供了所有开箱即用的bug修复和WF版本。 我还没有调查究竟4.5还没有被我们的客户认可，而是急切地等待着这个机会。
我急切希望的是，我们的客户不要求更改策略（因此也不需要修改工作stream程），而且当前的工作stream程没有任何错误。 后者是一个虚荣和空虚的希望，因为错误总是popup。
我真的不明白WF开发团队脑子里到底发布了一个什么样的开箱即用的系统，不能轻易修复漏洞。 他们应该开发一种将实例重新绑定到新的xamlx的技术。
