您使用 Windows Workflow Foundation 的体验如何？
我正在评估 WF 在网络上的业务应用程序中的使用，并且我很想听到有关该技术的一些最新第一手资料。
我的主要兴趣是提高项目的可维护性，也许还在于提高开发人员在处理频繁变化的复杂流程时的生产力。
我真的很喜欢 WF 的想法，但它似乎相对不为人知，而且我遇到的许多较早的评论都提到，一旦你进入它，它就会变得极其复杂。
如果它被过度设计到对于中小型项目来说不可用（或者是一个糟糕的权衡），那就是我需要知道的事情。
当然，它从2006年底就已经出来了，所以也许它已经成熟了。 如果是这样的话，这就是另一条非常有帮助的信息！
提前致谢！
I am evaluating WF for use in line of business applications on the web, and I would love to hear some recent first-hand accounts of this technology.
My main interest here is in improving the maintainability of projects and maybe in increasing developer productivity when working on complex processes that change frequently.
I really like the idea of WF, however it seems to be relatively unknown and many older comments I've come across mention that it's overwhelmingly complex once you get into it.
If it's overdesigned to the point that it's unusable (or a bad tradeoff) for a small to medium-sized project, that's something that I need to know.
Of course, it has been out since late 2006, so perhaps it has matured. If that's the case, that's another piece of information that would be very helpful!
Thanks in advance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
Windows Workflow Foundation 是一款功能非常强大的产品，但仍处于第一个版本:-(
使用的主要原因包括：
因此大多数时候您需要使用 WCF 来编写实例化 WF 运行时的主机。托管在 IIS 中是一个可行的解决方案，可以节省大量工作，但是 WCF/WF 耦合并不完美，需要进行一些认真的工作。 /2008/08/06/using-a-transactionscopeactivity-with-a-wcf-receiveactivity.aspx" rel="nofollow noreferrer">http://msmvps.com/blogs/theproblemsolver/archive/2008/08/06/使用-a-transactionscopeactivity-with-a-wcf-receiveactivity.aspx 了解更多详细信息。 预计下一版本会有相当多的更改/增强。
WF（和 WCF）对于 Microsoft 的许多新产品来说非常核心。 您可以期待 PDC 期间发布一些有趣的公告。
顺便说一句，保持工作流的多个版本运行需要一些工作，但这主要是标准的 .NET。 我刚刚就这个主题发表了一系列博客文章，从这里开始： http://msmvps.com/blogs/theproblemsolver/archive/2008/09/10/versioning-long-running-workfows.aspx
关于可视化建模业务需求。
从理论上讲，这在意图和实现分离的情况下效果很好。 然而，在实践中，纯粹出于技术原因，您将在工作流程中放弃相当多的额外活动，这违背了目的，因为您必须告诉业务分析师忽略一半的形状和线条。
Windows Workflow Foundation is a very capable product but still very much in its 1st version :-(
The main reasons for use include:
WF comes as a library/framework so most of the time you need to write the host that instantiates the WF runtime. That said, using WCF hosted in IIS is a viable solution and saves a lot of work. However the WCF/WF coupling is less than perfect and needs some serious work. See here http://msmvps.com/blogs/theproblemsolver/archive/2008/08/06/using-a-transactionscopeactivity-with-a-wcf-receiveactivity.aspx for more details. Expect quite a few changes/enhancements in the next version.
WF (and WCF) are pretty central to a lot of the new stuff coming out of Microsoft. You can expect some interesting announcements during the PDC.
BTW keeping multiple versions of a workflow running takes a bit of work but that is mostly standard .NET. I just did a series of blog posts on the subject starting here: http://msmvps.com/blogs/theproblemsolver/archive/2008/09/10/versioning-long-running-workfows.aspx
About visually modeling business requirements.
In theory, this works quite well with a separation of intent and implementation. However, in practice, you will drop quite a few extra activities on a workflow purely for technical reasons, and that sort of defeats the purpose as You have to tell a business analyst to ignore half the shapes and lines.
相关问题：何时使用 Windows Workflow Foundation？ 我的回答：
所以，如果你有这样的要求，那么WF是一个不错的选择。 当然它相对复杂，但要提到的是，试图解决的问题也很复杂（有时非常复杂）。 恕我直言，例如对附加了事件处理程序的对象进行脱水/再水化（当对象不在内存中时可以触发事件）是非常复杂的。
我无法判断你所说的“中小型项目”是什么意思，但总的来说，我会说，如果你的项目至少有上面列表中的两个要求，那么你可以考虑使用 WF 作为解决方案。
Related question: When to use Windows Workflow Foundation? My answer there:
So, if you have such requirements, then WF is a good candidate. Of course it is relatively complex, but mention that the problems that is trying to solve is also complex (and sometimes very complex). IMHO, it is very complex for example to dehydrate/rehydrate objects that have event handlers attached (with events that can be triggered when the object is not in memory).
I can not judge what you mean by "small to medium-sized project", but in general I would say that if your project has at least two requirements from the above list, then you can consider WF as a solution.
我们已经在大型 SharePoint 应用程序中使用了 WF，我可以说它没问题。 它具有强大的功能和灵活性。 而且，正如 Kevin 提到的，一旦您掌握了工作流程的基本概念，您就可以用它做几乎任何您想做的事情。
另一方面，它存在一些非常严重的问题，例如缺乏版本控制，这可能会在将来真正损害您的应用程序。 我们被迫部署同一工作流程的最多 3 个并行版本（名为 xxx-v1、xxx-v2 和 xxx-v3），以保持旧实例运行并让新实例使用更新版本。 真是让人头疼。 哦，其中还有一些非常不直观的概念（相关标记，wtf？）
We've used WF in a large-ish SharePoint application and I can say it's OK. It has lots of power and flexibility. and, as Kevin mentions, once you grok the underlying concepts of workflows, you can do pretty much anything you want with it.
On the other hand, it has some really serious issues, like lack of versioning, which can really hurt your application in the future. We've been forced to deploy up to 3 parallel versions of the same workflow named xxx-v1, xxx-v2 and xxx-v3 to keep older instances running and have new instances use the updated versions. A real pain in the ass. Oh, and there are also some really non-intuitive concepts in there (correlation tokens, wtf??)
我们有一个工作项目，我参与使用工作流程。
（来自管理层）的想法是，我们程序员将编写工作流活动以及“引擎”和框架。 然后，非程序员将通过将自己的工作流程编译成引擎会自动加载的 dll 来处理剩下的所有事情。
管理层相信非程序员使用工作流来帮助开发软件的想法，这几乎完全是浪费时间。 我们试图通过这个项目解决的问题相对复杂，我们从一开始就知道软件几乎必须不断修改（其计算取决于其他公司和政府）。
最终结果是我们无法使工作流程模块足够通用以供其他人使用。 因此，程序员是被迫使用工作流程的人，而工作流程所做的一切都妨碍了我们。
We had a project at work that I was involved in using Workflows.
The idea (from management), was that us programmers would write the Workflow Activities along with the "engine" and framework. Then non-programmers would take care of all the rest by compiling their own Workflows into dlls which the engine would automatically load.
Management was sold on this idea of non-programmers using Workflow to help develop software, and it was pretty much a complete waste of time. The problem we were trying to solve with this project was relatively complex and we knew from the very beginning that the software would have to be modified almost constantly (its calculations were dependent on other companies and governements).
The end result was that we were unable to make the Workflow modules generic enough for anyone else to use. So the programmers were the ones who were forced to work with the Workflows, and all the Workflows did was get in our way.
过去几个月我一直在使用 Workflow 4.0，尽管给我留下了深刻的印象，但我发现它非常难学。
对于最新版本（随 .NET 4.0 RC 一起提供），网络上、任何书籍中都几乎没有文档，也没有可用的培训课程。 我只找到与现已失效的 3.0 版本相关的文章。 甚至 MSDN 文档也缺乏实际意义。
工作流程设计器无论如何都没有应有的直观，因此学习非常困难。 我不得不依赖 StackOverflow 上一个人的答案（顺便感谢莫里斯！）——如果没有他的帮助，我会吃饱的。
总而言之，我认为它有潜力，但你会很疯狂地学习它 - 等待更多的培训、文档和书籍，否则你会盲目地进入它！
I've been using Workflow 4.0 for the last few months and although mostly impressed, I've found it extremely hard to learn.
For the most recent version (that comes with .NET 4.0 RC), there is next-to-no documentation on the web, in any books or no training courses available. I've only found articles relating to the now defunct 3.0 version. Even the MSDN documenation is light on the ground.
The workflow designer is not as intuitive as it should be by any means so learning is very hard. I've had to rely on answers from a single person on StackOverflow (thanks by the way Maurice!) - and I would be stuffed without his help.
So in summary, I think it has potential but you would be quite mad to learn it yet - wait for more training, documentation and books otherwise you will be going into it blind!
去年，我们与 WF 完成了一个工作应用程序，现在用作一个令人难以置信的庞大系统的骨干，该系统被一家非常大的银行用于其抵押贷款流程。 PE流程有很多步骤，从客户申请到信贷审批。
虽然很成功，但一路上也遇到了很多问题和危机。 对于任何较小规模的项目来说，这是不值得的。
Last year we completed a working application with WF, now used as the backbone of an unbelievably huge system which is used by a very big bank for its mortgage process. The pe process has many steps starting from customer application to approval of credit.
Although it was a success, there were so many problems and crisis all along the way. And it wont worth the trouble for any smaller size projects.
我认为 MS WF 是一个低级工作流库，而不是像 K2 这样成熟的企业工作流产品。 它将使您能够构建支持工作流的应用程序，但其本身并不是工作流应用程序。 我在这方面的经验是积极的，尽管我们必须围绕它构建许多我们自己的基础设施（发布/订阅框架、工作流生命周期管理器等）。 许多文档相当简单，没有涵盖构建基于 MS WF 的企业工作流应用程序。
I consider MS WF as a low-level workflow library rather than a fully fledged enterprise workflow product such as K2. It will enable you to build a workflow enabled application, but is not in itself a workflow application. My experiance of it in this capacity has been positive, although we have had to build a lot of our own infrastructure around it (a pub/sub framework, a worlkflow lifetime manager etc). A lot of the documentation out there is fairly simplistic and does not cover building up an enterprise workflow application based on MS WF.
Brian，我无法回复您的评论，但无论如何，通过版本控制，我的意思是在不破坏已经运行的实例的情况下对工作流程的底层代码进行更改，并优雅地将更新应用到现有工作流程。 我不确定“库存”WF，但至少在 SharePoint 环境中没有工作流版本的概念，因此必须将新版本部署为完全不同的工作流，这成为维护的噩梦。
这与“补水”无关，补水是在发生某些事件或状态更改后将“休眠”工作流程恢复到活动状态的过程。 这是由工作流运行时透明处理的。
Brian, I can't reply to your comment, but anyway, by versioning i mean making changes to the underlying code of the workflow without breaking already running instances, and gracefully applying updates to existing workflows. I'm not sure about 'stock' WF, but at least in SharePoint environment there's no concept of workflow versions so new versions have to be deployed as completely different workflows which becomes a maintenance nightmare.
This has nothing to do with 'rehydration', rehydration is the process by which you bring a 'dormant' workflow back to activity after some event or change in state. That is handled transparently by the workflow runtime.
这实际上取决于您想用它做什么。 我只使用了一点，但与 MetaStorm（我知道技术上它是一个 BPM，但仍然有工作流组件）、Process Choriographer 和 IBM MQ 工作流等更成熟的产品相比，没有可比性。 只是还不够成熟。 另一方面，它是免费的，而其他的则不然，并且可能可以完成工作。 我不知道我是否会对其进行数百万美元的手术，但对于较小的手术，我会再试一次。 你将面临的真正障碍是它所需要的思维过程的改变。 如果您没有以前使用过状态系统的开发人员，那么这可能是一个真正的障碍。
It really depends on what you want to do with it. I've only used it a little, but compared to more mature products like MetaStorm (I know technically it's a BPM, but there is still a workflow component), Process Choriographer and IBM MQ workflow, there's no comparison. It's just not mature enough. On the other hand it's free where the others are not and can probably get the job done. I don't know if I would place a multi-million dollar operation on it, but with smaller ones, I'd give it another shot. The real hurdle you are going to face is the change in thought process it requires. If you don't have developers that have worked with state systems before that can be a real hurdle.
很难学。 相当灵活。 不要与最终用户的可视化工具混淆，仅适用于程序员。 不确定我是否喜欢依赖财产方法。
Hard to learn. Quite flexible. Not to be confused with a visual tool for end users, only for programmers. Not sure if I like the dependancy property approach.
WF已集成到SharePoint（WSS 3.0）中，并且我已经为各种SharePoint网站创建了相当多的工作流程，因此我可以讲述我在SharePoint中使用WF的经验。 与其他工作流框架相比，WF 得分很高。 它很稳定（我没有遇到任何神秘的错误），工作流程相当容易设计（感谢 Visual Studio 中的工作流程设计器），您不仅可以使用顺序工作流程，还可以使用状态机工作流程。
当然，它并不完美，开发人员肯定需要一些时间来理解这个概念（即活动模型）； 但它绝对有用 - 即使对于“小任务”也是如此。
WF ist integrated into SharePoint (WSS 3.0), and i have created quite a few workflows for various SharePoint-Websites, so i can tell about my experience of WF in SharePoint. Compared with other workflow-frameworks WF scores well. It's stable (i haven't experienced any mysterious errors), workflows are fairly easy to design (thank to the workflow-designer in Visual Studio) and you can use not only sequential but also state-machine workflows.
It's not perfect, of course, and a developer will definitly need some time to understand the concept (of i.e. the Activity Model); but it's definitely useable - even for "small tasks".
从未尝试过 WFF，但我记得读过Leon Bambrick 写的这篇关于 WFF 的文章，他基本上在其中说整个软件开发工具类型都是无稽之谈。 可能会帮助您决定一种方式或另一种方式。
Never tried WFF, but I remember reading this article about WFF by Leon Bambrick where he basically says the whole genre of software development tools is nonsense. Might help you decide one way or the other.