I have done several WF4 projects so lets see if I can add any useful info to the other answers.
From the description of your business problem it sounds like WF4 is a good match, so no problems there.
Regarding your concerns you are right. Basically WF4 is a new product and is lacking some important features and has some rough edges. There is a learning curve, you do have to do some things differently. The main point is long running and serialization, which is something the average developer is not used to and requires some thought to get right as I hear far too often that people have problems serializing an entities framework data context.
Most of the time using workflow services hosted in IIS/WAS is the best route when doing these long running type of workflows. That makes solving the versioning problem not to hard either, just have the first message return the workflow version and make that a part of each subsequent message. Next put the WCF router in between that routes the message to the correct endpoint based on the version. The basic is never to change an existing workflow, always create a new one.
So what is my advise to you? Don't take a big gamble on a unknown, and for you unproven, piece of technology. Do a small, non critical, piece of the application using WF4. That way if it works you can expand on it but if it fails you can rip it out and replace it with more traditional .NET code. That way you get real experience with WF4 instead of having to base a decision on second hand information and you learn a new and powerful technology in the process. If possible take a course on WF4 as that will save you a lot of time in getting up to speed (shameless self plug here).
About the Simple State Machine. I have not used it but I was under the impression it was for short running, in memory, state machines. One of the main benefits of WF4 is the long running aspects.
I have come to this dilemma couple of times and I had chosen not to use Work Flow foundation. Some of considerations (similar to yours) were
Involved work flows were lot simpler (a combination of state machine and sequential actions) and doing it in WF seems to overkill for efforts involved.
Learning curve for developers to understand and to use WF effectively was considered high. Status transition table describing valid transitions and actions to be taken are used for additional flexibility and developers were comfortable with it, easily understanding the concept and purpose.
Chances of business process changes were slim and rudimentary changes were easily possible with help of transition table. A change in transition would mean a database script while change in actions would result in new release/patch. However, probability of such occurrence was deemed to be low.
Looking back after 13-14 months, I still think that decision of not using WF was correct. IMO, WF makes sense where there is strong likely hood that work flow can change and/or business rules can change. WF allows to isolate workflow in separate file and so making it configurable by users will be simpler.
We have been using WF 4.0 the last couple of months. I have to say it's challenging to think the Workflow way. However, I can tell you it's worth it. We knew very little when we started. We've bought a beginner and professional book for WF 4.0 that helped. I, myself, watched many videos online and followed PDC 2009 for their breaking news about WF 4.0 and how it's different from the previous somewhat sucky versions. One major thing that we had to propose a solution for is the way we can deal with In/Our Arguments in a workflow without bounding our custom activities to certain data types and how to pass parameters between activities. I have come up with a good solution for that, and the workflow experience that we have so far is not bad at all. Actually, we have a workflow-intensive application that is getting bigger and bigger and I really cannot imagine myself solving it in a different environment. I love the visual effect that it has: it keeps me away from the details of if/else etc constructs and makes the business rules apparent in a way that doesn't make you forced to dive into lines of code to know what's going on or how to fix some bug. By the way, the project that we worked on is very similar to what you described and it's a medium-sized project. You can tell from my words that I like it and I do recommend it although is incorporates some risks as it's a new technology and you have to come up with some innovative ideas.
I did three projects in WF 3.5 and I have to say it is not easy. It force you to think in the whole new way especially when persistance is used. Updating the application which contains hundreds of incomplete persisted workflow is challenging. Single breaking change in serialization crashes them all. Introducing multiple versions of the same library to support new and old running workflows is common. It was challenging.
I haven't tryed WF 4.0 yet but based on experience from BizTalk and WF 3.5 I think it will be similar.
Anyway the best approach you can take is to do Proof-of-Concept. Take single WF from your requirments and try to implment it in WF 4.0. You will spend some time with it but you will prove if you are able to do that in WF 4.0 and if there are any visible benefits.
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.
程序员在转向这项技术时遇到的两个主要概念问题是： a) 消息关联和消息交换模式 b) 工作流程和单元测试 例如，在 C# 的标准系统中，工作流程很少是明确的，因此很少进行单元测试。整个工作流程留给验收场景或集成进行测试。引入显式 WF 作为软件工件，标准开发人员突然想要尝试对其进行单元测试，但这通常不值得做。
I think it does not really make sense today to talk about Workflow in WF4 as a technology choice for this kind of problem. What is really appropriate, as mentioned by Ladislav Mrnka above, is WCF WF Services hosted in AppFabric.
My experience with this is that it pays great dividends and is very enjoyable, but problems arise in the beginning because it is not properly appreciated that for many programmers this is a methodology shift more than a technology shift. On the other hand, generalists and those with a problem-solving mindset saw WCF WF AppFabric as a set of exciting opportunities. So if the mix of people on the project are fairly conservative C# devs attached to their daily set of OO and patterns, it will be hard to introduce. If the team is more innovative, then adoption will be much easier because the potential and new doorways multiply with each discovery.
Two main conceptual problems programmers had in moving to this technology was: a) Message correlation and messaged exchange patterns b) Workflows and unit testing In standard systems in C# for example a workflow is rarely explicit and therefore rarely unit tested. The overall workflow is left for testing by acceptance scenarios or integration. Introduce an explicit WF as a software artifact and suddenly standard devs want to try and unit test it, which is usually not worth doing.
The message correlation aspect of it is a bit of mindset shift for those not familiar with message exchange patterns. Most devs have dealt with in process and remote calls, web service and SOAP, and usually focussed on one or two of those. To abstract above it all and work with a general message based system can be confusing at first.
On the positive side though, the end result is something that saves a lot of time and creates a lot of opportunities. One main thing is that the worfklow, if visually clear, is something that can be worked on by end user, developer and analyst together, eliminating unnecessary steps in the development lifecycle and focusing the parties on one artifact. Further, it discourages islands of functionality in dedicated apps, with dedicated glue layers, by encouraging a suite of business processes in WF per business domain. Further, with AppFabric, the plumbing for persistence, logging, and waking up scheduled activities is all done for you. WF4 performance is outstanding too.
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.
为了构建涉及角色和“子任务”的任何复杂性的保险索赔系统，您确实需要 BPM 解决方案，而不仅仅是工作流程。 Workflow Foundation 4.0 很灵活，但它确实与 BPM 产品的功能相差不远。
BPM 解决方案（例如 Metastorm BPM、Global360 和 K2.NET）提供以人为中心的工作流程、任务、角色和系统集成，可以建模和简化保险索赔系统等业务流程。使用 ASP.NET 构建与 BPM 工作流引擎集成的界面，因为它们的内置设计器通常受到限制，并迫使您使用其自定义构建的 Web 控件，这些控件通常不如 ASP.NET Web 控件功能齐全。
In order to do an insurance claim system of any complexity that involves roles and "sub-tasks" you really need an BPM solution, not just workflow. Workflow Foundation 4.0 is slick but it really doesn't not come close to the functionalities of a BPM product.
BPM solutions, like Metastorm BPM, Global360, and K2.NET, provide human centric workflow, tasks, roles, and system integration that can model and streamline the business processes like your insurance claim system. Use ASP.NET to build the interface that integrates with the BPM workflow engine as their built in designers are usually limited and force you to use their custom built web control which usually are not as full featured as the ASP.NET web controls.
Go with the technology your team knows and feels comfortable with. Workflow Foundation is not a product that you can use straight away - it's rather a set of pieces you can embed in your application in order to build a workflow system. IMHO the workflow logic is the least important piece of technology, first of all you have to concentrate on the GUI because business owners will not see anything but the GUI. But if your system is a success then you have to be prepared for neverending change requests and new requirements so you have to implement your business logic so that it's easy to change and easy to divide into separate processes to suit different user needs (sometimes contradicting). BPM helps in this task because it allows you to have separate, multiple versions of business processes suiting various business needs. You don't need full fledged BPM engine for that but it's useful to code your business logic so that it can be versioned and divided into individual business processes - the worst thing to have is an unmantainable and intertangled blob of code that handles 'everything' and that no one can understand. There are many ideas for that - state machines, DSLs (domain specific languages), scripts etc - you decide what the implementation should be. But you should always think in terms of business processes and organize your logic accordingly so that it reflects these processes. And be prepared for coexistence of many variants of business logic and data structures - this is the most difficult design task imho.
I'm in a situation where I have to use 4.0 as .NET 4.5 isn't accredited for use in our prod environment yet. I had major pain understanding generally how to get long running workflows going to suit our business need but eventually found an elegant solution. It's not something which just anyone coming later to support can just pick up with ease because there's so much to think about, but I do believe in WF as a tool for managing workflow states.
One big thing I take issue with WF 4.0 though is Maurice's comment:
The basic is never to change an existing workflow, always create a new one
That's great if you just want a new version, but what if you have 50,000 persisted workflows and realise at some point that there's a bug in the workflow? You need to be able to update the xamlx and still be coupled to the existing instances. I've tried ungzipping the various metadata columns in the SQL Server instances table to find something that ties the instance to the workflow definition without any luck.
I did write a synchronisation application for importing data from an old system into our new WF 4.0 driven one. We basically load the data into the system, then run the process which goes about automatically calling into the workflow steps and calling validation methods, essentially mocking user interaction. This only really worked well with us due to the architecture we implemented for access to the workflow service host. It's great as a one off, where after running you can go through and do checks to ensure consistency of the data migration process, but having to use this approach for potentially hundreds of thousands of cases once a system is live isn't really an approach that instills confidence and over burdens the process of integration simple bug fixes.
My recommendation is that you avoid WF 4.0 altogether and just go straight to 4.5 if you're environment supports it. The Dynamic Updates and Side by Side Versioning it provides caters for bug fixing and WF versioning all out of the box. I've still yet to investigate exactly how as 4.5 still isn't accredited for use by our client, but eagerly awaiting this opportunity.
What I'm desperately hoping for is that our client doesn't request changes to policy (and therefore workflow adjustments) and that the current workflows hold up without any bugs. The latter being a vain and empty hope as bugs always pop up.
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.
发布评论
评论（8）
我已经完成了几个 WF4 项目，所以让我们看看是否可以在其他答案中添加任何有用的信息。
从您的业务问题的描述来看，WF4 听起来很匹配，所以没有问题。
关于您的担忧，您是对的。基本上，WF4 是一个新产品，缺乏一些重要的功能，并且有一些粗糙的地方。有一个学习曲线，你确实必须以不同的方式做一些事情。要点是长时间运行和序列化，这是普通开发人员不习惯的，并且需要一些思考才能正确，因为我经常听说人们在序列化实体框架数据上下文时遇到问题。
大多数时候，在执行这些长时间运行的工作流类型时，使用 IIS/WAS 中托管的工作流服务是最佳途径。这使得解决版本控制问题也不难，只需让第一条消息返回工作流版本并将其作为每个后续消息的一部分即可。接下来将 WCF 路由器置于两者之间，根据版本将消息路由到正确的终结点。基本原则是永远不要改变现有的工作流程，而总是创建一个新的工作流程。
那么我给你的建议是什么？
不要在未知的、对你而言未经证实的技术上进行大赌注。使用 WF4 执行一小部分非关键应用程序。这样，如果它有效，您可以对其进行扩展，但如果它失败，您可以将其删除并用更传统的 .NET 代码替换。这样您就可以获得 WF4 的真实体验，而不必根据二手信息做出决定，并且在此过程中您可以学到强大的新技术。如果可能的话，参加 WF4 课程，因为这会节省你大量的时间来加快速度（无耻的自我插件 此处）。
关于简单状态机。我没有使用过它，但我的印象是它是在内存、状态机中短期运行的。 WF4 的主要优点之一是长期运行方面。
I have done several WF4 projects so lets see if I can add any useful info to the other answers.
From the description of your business problem it sounds like WF4 is a good match, so no problems there.
Regarding your concerns you are right. Basically WF4 is a new product and is lacking some important features and has some rough edges. There is a learning curve, you do have to do some things differently. The main point is long running and serialization, which is something the average developer is not used to and requires some thought to get right as I hear far too often that people have problems serializing an entities framework data context.
Most of the time using workflow services hosted in IIS/WAS is the best route when doing these long running type of workflows. That makes solving the versioning problem not to hard either, just have the first message return the workflow version and make that a part of each subsequent message. Next put the WCF router in between that routes the message to the correct endpoint based on the version. The basic is never to change an existing workflow, always create a new one.
So what is my advise to you?
Don't take a big gamble on a unknown, and for you unproven, piece of technology. Do a small, non critical, piece of the application using WF4. That way if it works you can expand on it but if it fails you can rip it out and replace it with more traditional .NET code. That way you get real experience with WF4 instead of having to base a decision on second hand information and you learn a new and powerful technology in the process. If possible take a course on WF4 as that will save you a lot of time in getting up to speed (shameless self plug here).
About the Simple State Machine. I have not used it but I was under the impression it was for short running, in memory, state machines. One of the main benefits of WF4 is the long running aspects.
我曾多次陷入这种困境，但我选择不使用工作流程基础。一些考虑因素（与您的类似）
13-14个月后回顾，我仍然认为不使用WF的决定是正确的。 IMO，当工作流程很可能发生变化和/或业务规则发生变化时，WF 是有意义的。 WF 允许将工作流程隔离在单独的文件中，因此用户可配置它会更简单。
I have come to this dilemma couple of times and I had chosen not to use Work Flow foundation. Some of considerations (similar to yours) were
Looking back after 13-14 months, I still think that decision of not using WF was correct. IMO, WF makes sense where there is strong likely hood that work flow can change and/or business rules can change. WF allows to isolate workflow in separate file and so making it configurable by users will be simpler.
过去几个月我们一直在使用 WF 4.0。我不得不说，以工作流程的方式思考是很有挑战性的。不过，我可以告诉你这是值得的。刚开始时我们知之甚少。我们购买了一本 WF 4.0 的初学者和专业书籍，这很有帮助。我本人在网上观看了许多视频，并关注了 PDC 2009，了解有关 WF 4.0 的突发新闻以及它与之前有些糟糕的版本有何不同。
我们必须提出解决方案的一件主要事情是，我们可以在工作流程中处理“内部/我们的参数”，而不将我们的自定义活动限制为某些数据类型，以及如何在活动之间传递参数。我已经为此提出了一个很好的解决方案，而且到目前为止我们所拥有的工作流程体验一点也不差。实际上，我们有一个工作流程密集型应用程序，而且规模越来越大，我真的无法想象自己在不同的环境中解决它。我喜欢它所具有的视觉效果：它让我远离 if/else 等构造的细节，并使业务规则变得显而易见，而不会让您被迫深入代码行来了解发生了什么或如何修复一些错误。
顺便说一句，我们从事的项目与您所描述的非常相似，并且是一个中型项目。
从我的话中你可以看出我喜欢它并且我确实推荐它，尽管它包含一些风险，因为它是一项新技术，你必须想出一些创新的想法。
我的2分钱...
We have been using WF 4.0 the last couple of months. I have to say it's challenging to think the Workflow way. However, I can tell you it's worth it. We knew very little when we started. We've bought a beginner and professional book for WF 4.0 that helped. I, myself, watched many videos online and followed PDC 2009 for their breaking news about WF 4.0 and how it's different from the previous somewhat sucky versions.
One major thing that we had to propose a solution for is the way we can deal with In/Our Arguments in a workflow without bounding our custom activities to certain data types and how to pass parameters between activities. I have come up with a good solution for that, and the workflow experience that we have so far is not bad at all. Actually, we have a workflow-intensive application that is getting bigger and bigger and I really cannot imagine myself solving it in a different environment. I love the visual effect that it has: it keeps me away from the details of if/else etc constructs and makes the business rules apparent in a way that doesn't make you forced to dive into lines of code to know what's going on or how to fix some bug.
By the way, the project that we worked on is very similar to what you described and it's a medium-sized project.
You can tell from my words that I like it and I do recommend it although is incorporates some risks as it's a new technology and you have to come up with some innovative ideas.
my 2 cents...
我在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 的开箱即用功能。
I did three projects in WF 3.5 and I have to say it is not easy. It force you to think in the whole new way especially when persistance is used. Updating the application which contains hundreds of incomplete persisted workflow is challenging. Single breaking change in serialization crashes them all. Introducing multiple versions of the same library to support new and old running workflows is common. It was challenging.
I haven't tryed WF 4.0 yet but based on experience from BizTalk and WF 3.5 I think it will be similar.
Anyway the best approach you can take is to do Proof-of-Concept. Take single WF from your requirments and try to implment it in WF 4.0. You will spend some time with it but you will prove if you are able to do that in WF 4.0 and if there are any visible benefits.
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 中的工作流作为此类问题的技术选择并没有多大意义。正如 Ladislav Mrnka 上面提到的，真正合适的是 AppFabric 中托管的 WCF WF 服务。
我的经验是，它会带来巨大的红利并且非常令人愉快，但一开始就会出现问题，因为没有正确认识到对于许多程序员来说，这是一种方法论的转变，而不是技术的转变。另一方面，通才和具有解决问题思维的人将 WCF WF AppFabric 视为一系列令人兴奋的机会。因此，如果项目中的人员都是相当保守的 C# 开发人员，执着于他们日常的 OO 和模式集，那么将很难进行介绍。如果团队更具创新性，那么采用就会更容易，因为每次发现都会带来更多的潜力和新的途径。
程序员在转向这项技术时遇到的两个主要概念问题是：
a) 消息关联和消息交换模式
b) 工作流程和单元测试
例如，在 C# 的标准系统中，工作流程很少是明确的，因此很少进行单元测试。整个工作流程留给验收场景或集成进行测试。引入显式 WF 作为软件工件，标准开发人员突然想要尝试对其进行单元测试，但这通常不值得做。
对于那些不熟悉消息交换模式的人来说，消息关联方面是一种思维方式的转变。大多数开发人员都处理过进程内调用和远程调用、Web 服务和 SOAP，并且通常关注其中的一两个。首先抽象并使用基于通用消息的系统可能会令人困惑。
但从积极的一面来看，最终结果是节省大量时间并创造大量机会。一件主要的事情是，如果视觉上清晰的话，工作流程可以由最终用户、开发人员和分析师共同处理，从而消除开发生命周期中不必要的步骤，并将各方集中在一个工件上。此外，它通过鼓励每个业务域在 WF 中使用一套业务流程，阻止专用应用程序中具有专用粘合层的功能孤岛。此外，借助 AppFabric，持久性、日志记录和唤醒计划活动的管道都已为您完成。 WF4的表现也很出色。
我的建议是找到最具创新性或探索性的团队成员进行初步侦察，以发现棘手的部分，让核心功能发挥作用，并让最初的人负责然后划分剩余的工作。
I think it does not really make sense today to talk about Workflow in WF4 as a technology choice for this kind of problem. What is really appropriate, as mentioned by Ladislav Mrnka above, is WCF WF Services hosted in AppFabric.
My experience with this is that it pays great dividends and is very enjoyable, but problems arise in the beginning because it is not properly appreciated that for many programmers this is a methodology shift more than a technology shift. On the other hand, generalists and those with a problem-solving mindset saw WCF WF AppFabric as a set of exciting opportunities. So if the mix of people on the project are fairly conservative C# devs attached to their daily set of OO and patterns, it will be hard to introduce. If the team is more innovative, then adoption will be much easier because the potential and new doorways multiply with each discovery.
Two main conceptual problems programmers had in moving to this technology was:
a) Message correlation and messaged exchange patterns
b) Workflows and unit testing
In standard systems in C# for example a workflow is rarely explicit and therefore rarely unit tested. The overall workflow is left for testing by acceptance scenarios or integration. Introduce an explicit WF as a software artifact and suddenly standard devs want to try and unit test it, which is usually not worth doing.
The message correlation aspect of it is a bit of mindset shift for those not familiar with message exchange patterns. Most devs have dealt with in process and remote calls, web service and SOAP, and usually focussed on one or two of those. To abstract above it all and work with a general message based system can be confusing at first.
On the positive side though, the end result is something that saves a lot of time and creates a lot of opportunities. One main thing is that the worfklow, if visually clear, is something that can be worked on by end user, developer and analyst together, eliminating unnecessary steps in the development lifecycle and focusing the parties on one artifact. Further, it discourages islands of functionality in dedicated apps, with dedicated glue layers, by encouraging a suite of business processes in WF per business domain. Further, with AppFabric, the plumbing for persistence, logging, and waking up scheduled activities is all done for you. WF4 performance is outstanding too.
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.
为了构建涉及角色和“子任务”的任何复杂性的保险索赔系统，您确实需要 BPM 解决方案，而不仅仅是工作流程。 Workflow Foundation 4.0 很灵活，但它确实与 BPM 产品的功能相差不远。
BPM 解决方案（例如 Metastorm BPM、Global360 和 K2.NET）提供以人为中心的工作流程、任务、角色和系统集成，可以建模和简化保险索赔系统等业务流程。使用 ASP.NET 构建与 BPM 工作流引擎集成的界面，因为它们的内置设计器通常受到限制，并迫使您使用其自定义构建的 Web 控件，这些控件通常不如 ASP.NET Web 控件功能齐全。
In order to do an insurance claim system of any complexity that involves roles and "sub-tasks" you really need an BPM solution, not just workflow. Workflow Foundation 4.0 is slick but it really doesn't not come close to the functionalities of a BPM product.
BPM solutions, like Metastorm BPM, Global360, and K2.NET, provide human centric workflow, tasks, roles, and system integration that can model and streamline the business processes like your insurance claim system. Use ASP.NET to build the interface that integrates with the BPM workflow engine as their built in designers are usually limited and force you to use their custom built web control which usually are not as full featured as the ASP.NET web controls.
采用您的团队了解且熟悉的技术。 Workflow Foundation 不是一个可以立即使用的产品 - 它是一组可以嵌入到应用程序中以构建工作流系统的组件。恕我直言，工作流逻辑是最不重要的技术，首先你必须专注于 GUI，因为企业主除了 GUI 不会看到任何东西。但是，如果您的系统成功，那么您必须为永无休止的变更请求和新需求做好准备，因此您必须实现业务逻辑，以便轻松更改并轻松划分为单独的流程，以满足不同的用户需求（有时是矛盾的） 。 BPM 有助于完成此任务，因为它允许您拥有适合各种业务需求的单独的多个版本的业务流程。为此，您不需要成熟的 BPM 引擎，但对业务逻辑进行编码非常有用，以便可以对它进行版本控制并将其划分为单独的业务流程 - 最糟糕的事情是处理“所有事情”的难以维护且相互交织的代码块没有人能理解。有很多想法 - 状态机、DSL（领域特定语言）、脚本等 - 您决定应该如何实现。但您应该始终根据业务流程进行思考，并相应地组织您的逻辑，以便它反映这些流程。
并为业务逻辑和数据结构的多种变体的共存做好准备——恕我直言，这是最困难的设计任务。
Go with the technology your team knows and feels comfortable with. Workflow Foundation is not a product that you can use straight away - it's rather a set of pieces you can embed in your application in order to build a workflow system. IMHO the workflow logic is the least important piece of technology, first of all you have to concentrate on the GUI because business owners will not see anything but the GUI. But if your system is a success then you have to be prepared for neverending change requests and new requirements so you have to implement your business logic so that it's easy to change and easy to divide into separate processes to suit different user needs (sometimes contradicting). BPM helps in this task because it allows you to have separate, multiple versions of business processes suiting various business needs. You don't need full fledged BPM engine for that but it's useful to code your business logic so that it can be versioned and divided into individual business processes - the worst thing to have is an unmantainable and intertangled blob of code that handles 'everything' and that no one can understand. There are many ideas for that - state machines, DSLs (domain specific languages), scripts etc - you decide what the implementation should be. But you should always think in terms of business processes and organize your logic accordingly so that it reflects these processes.
And be prepared for coexistence of many variants of business logic and data structures - this is the most difficult design task imho.
我面临的情况是，我必须使用 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 的技术。
I'm in a situation where I have to use 4.0 as .NET 4.5 isn't accredited for use in our prod environment yet. I had major pain understanding generally how to get long running workflows going to suit our business need but eventually found an elegant solution. It's not something which just anyone coming later to support can just pick up with ease because there's so much to think about, but I do believe in WF as a tool for managing workflow states.
One big thing I take issue with WF 4.0 though is Maurice's comment:
That's great if you just want a new version, but what if you have 50,000 persisted workflows and realise at some point that there's a bug in the workflow? You need to be able to update the xamlx and still be coupled to the existing instances. I've tried ungzipping the various metadata columns in the SQL Server instances table to find something that ties the instance to the workflow definition without any luck.
I did write a synchronisation application for importing data from an old system into our new WF 4.0 driven one. We basically load the data into the system, then run the process which goes about automatically calling into the workflow steps and calling validation methods, essentially mocking user interaction. This only really worked well with us due to the architecture we implemented for access to the workflow service host. It's great as a one off, where after running you can go through and do checks to ensure consistency of the data migration process, but having to use this approach for potentially hundreds of thousands of cases once a system is live isn't really an approach that instills confidence and over burdens the process of integration simple bug fixes.
My recommendation is that you avoid WF 4.0 altogether and just go straight to 4.5 if you're environment supports it. The Dynamic Updates and Side by Side Versioning it provides caters for bug fixing and WF versioning all out of the box. I've still yet to investigate exactly how as 4.5 still isn't accredited for use by our client, but eagerly awaiting this opportunity.
What I'm desperately hoping for is that our client doesn't request changes to policy (and therefore workflow adjustments) and that the current workflows hold up without any bugs. The latter being a vain and empty hope as bugs always pop up.
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.