Personally, I'm not sold on WF. It's usefulness wasn't as obvious to me as other new MS technologies, like WPF or WCF.
I think WF will be used heavily in business applications in the future, but I have no plans to use it because it doesn't seem like the right tool for the job for my projects.
In general, if you do not need the persistence and tracking features (which in my opinion are the main features), you shouldn't use Workflow Foundation.
Here are the advantages and disadvantages of Workflow Foundation I gathered from my experience:
Advantages
Persistence: If you're going to have many long running processes (think days, weeks, months), then Workflows are great for this. Idle workflow instances are persisted to the database so it doesn't use up memory.
Tracking: WF provides the mechanism to track each activity executed in a workflow
*Visual Designer: I put this as a *, because I think this is really only useful for marketing purposes. As a developer, I prefer to write code rather than snapping things together visually. And when you have a non-developer making workflows, you often end up with a huge confusing mess.
Disadvantages
Programming Model: You're really limited in programming features. Think about all the great features you have in C#, then forget about them. Simple one or two line statements in C# becomes a fairly large block activities. This is particularly a pain for input validation. Having said that, if you're really careful to keep only high-level logic in workflows, and everything else in C#, then it might not be a problem.
Performance: Workflows use up a large amount of memory. If you're deploying a lot of workflows on a server, make sure you have tons of memory. Also be aware that workflows are much slower than normal C# code.
Steep learning curve, hard to debug: As mentioned above. You're going to spend a lot of time figuring out how to get things to work, and figuring out the best way to do something.
Workflow Version Incompatibility: If you deploy a workflow with persistence, and you need to make updates to the workflow, the old workflow instances are no longer compatible. Supposedly this is fixed in .NET 4.5.
You have to use VB expressions (.NET 4.5 allows for C# expressions).
Not flexible: If you need some special or specific functionality not provided by Workflow Foundation, prepare for a lot of pain. In some cases, it might not even be possible. Who knows until you try? There's a lot of risk here.
WCF XAML services without interfaces: Normally with WCF services, you develop against an interface. With WCF XAML Services, you cannot ensure a WCF XAML Service has implemented everything in an interface. You don't even need to define an interface. (as far as I know...)
Doesn't provide enough power, flexibility, or productivity gain to justify its use
Can and will corrupt application state that cannot be recovered
The only time I could ever conceive of using WF is if I wanted to host the designer for an end-user and probably not even then.
Trust me, nothing will ever be as straightforward, powerful, or flexible as the code that you write to do exactly what you need it to do. Stay away from WF.
Of course, this is only my opinion, but I think it's a damn good one. :)
The code generated by WF is nasty. The value that WF brings is in the visual representation of the system, although I have yet to see anything (6-7 projects at work now with WF that i've been involved with) where I would not have preferred a simpler hand coded project.
The major reason I've found for using workflow foundation is how much it brings you out of the box in terms of tracking and persistence. It's very easy to get the persistence service up and running, which brings reliability and load distribution between multiple instances and hosts.
On the other hand, just like forms apps, the code patterns that the workflow designer pushes you towards are bad. But you can avoid problems by writing no code in the workflow and delegating all work to other classes, which can be organized and unit tested more gracefully than the workflow. Then you get the cool visual aspect of the designer without the cruft of spaghetti code behind.
我目前工作的公司建立了 Windows Workflow Foundation (WF)，他们选择使用它的原因是因为规则会经常更改，这将迫使他们重新编译各种 dll 等，因此他们的解决方案是将规则放置在数据库中并从那里调用它们。 这样他们就可以改变规则，而不必重新编译和重新分发 dll 等。
The company I am currently working for set up a Windows Workflow Foundation (WF) and the reasons they chose to use it was because the rules would frequently be changing and that would force them to do a recompile of the various dll's etc and so their solution was to place the rules in the DB and call them from there. This way they could change the rules and not have to recompile and redistribute the dlls etc.
Windows 工作流像它的表亲 BizTalk 一样吸引着非编码 IT 经理、BA 等，但在实践中，单元测试、调试和代码覆盖率只是众多陷阱中的三个。 您可以克服其中一些问题，但您必须投入大量资金才能实现这一点，而使用纯代码您就可以做到这一点。 如果您确实有长期运行的需求，那么您可能需要更复杂的东西。 我听说过关于能够在不重新编译 dll 的情况下将新的 xaml 文件投入生产的争论，但说实话，工作流消耗的时间可以更好地用于改进持续集成，使编译部署不再成为问题。
Windows Workflows seduce non-coding IT managers, BAs and the like as does its cousin BizTalk but in practice unit testing, debugging and code coverage are just three of the many pitfalls. You can overcome some of them but you have to invest heavily in achieving that whereas with plain code you just get that. If you genuinely have a long-running requirement then you probably need something more sophisticated. I've heard the argument about being able to drop new xaml files into production without re-compiling dlls but honestly the time that Workflows will consume could be better used to improve your Continuous Integration to the point where compiled deploys aren't a problem.
I would use it in any environment where I need to work with workflow, however when using it in conjuction with K2 or even SharePoint 2007 the power of the platform is truly useful. When developing business applications with BI specialist the use of the platform is recommended and this would normally only be relevant to streamline and improve business processes.
For the record WF was developed in conjunction with K2's development team and the new K2 Blackpearl is built on top of WF, so is MOSS 2007 and WSS 3.0's workflow engines.
I have been using Windows workflow for months now to develop custom activities and a re-hosted designer that non-developers can use to build workflows. WF is very powerful but it is only as good as the custom activities that are built by developers. When it comes down to it, a developer would have to look over workflows built by non-developers to test and debug but from the point they can create draft workflows- that is fantastic.
Furthermore, in cases where you have long running processes WF is a good tech stack to use when you need to update processes dynamically - without having to reinstall/download or do anything, just add the new XAML files to a directory and your architecture should be set up with versioning to scrap the old one and use the new one.
发布评论
评论（11）
就我个人而言，我不喜欢WF。 对我来说，它的用处并不像其他新的 MS 技术（例如 WPF 或 WCF）那么明显。
我认为 WF 将来会在业务应用程序中大量使用，但我没有计划使用它，因为它似乎不是适合我的项目的合适工具。
Personally, I'm not sold on WF. It's usefulness wasn't as obvious to me as other new MS technologies, like WPF or WCF.
I think WF will be used heavily in business applications in the future, but I have no plans to use it because it doesn't seem like the right tool for the job for my projects.
一般来说，如果您不需要持久性和跟踪功能（我认为这是主要功能），则不应使用 Workflow Foundation。
以下是我从我的经验中总结出的 Workflow Foundation 的优点和缺点：
优点
缺点
In general, if you do not need the persistence and tracking features (which in my opinion are the main features), you shouldn't use Workflow Foundation.
Here are the advantages and disadvantages of Workflow Foundation I gathered from my experience:
Advantages
Disadvantages
仅当满足以下任一条件时，您才可能需要 WF：
有关更多详细信息，请参阅 Paul Andrew 的帖子：使用 Windows Workflow Foundation 做什么？
请不要将 WF 与任何类型的可视化编程混淆或联系起来。 这是错误的，可能会导致非常糟糕的架构/设计决策。
You may need WF only if any of the following are true:
For more details, see Paul Andrew's post: What to use Windows Workflow Foundation for?
Please do not confuse or relate WF with visual programming of any kind. It is wrong and can lead to very bad architecture/design decisions.
绝不。 您可能会后悔：
我唯一能想到使用 它WF 是指如果我想为最终用户托管设计器，甚至可能也不会。
相信我，没有什么比您编写的代码更简单、更强大或更灵活，可以完全满足您的需要。 远离WF。
当然，这只是我的观点，但我认为这是一个非常好的观点。 :)
Never. You will probably regret it:
The only time I could ever conceive of using WF is if I wanted to host the designer for an end-user and probably not even then.
Trust me, nothing will ever be as straightforward, powerful, or flexible as the code that you write to do exactly what you need it to do. Stay away from WF.
Of course, this is only my opinion, but I think it's a damn good one. :)
WF 生成的代码很糟糕。 WF 带来的价值在于系统的视觉表示，尽管我还没有看到任何我不喜欢更简单的手工编码项目的东西（我参与过的 WF 现在有 6-7 个项目） 。
The code generated by WF is nasty. The value that WF brings is in the visual representation of the system, although I have yet to see anything (6-7 projects at work now with WF that i've been involved with) where I would not have preferred a simpler hand coded project.
我发现使用工作流基础的主要原因是它在跟踪和持久性方面给您带来了很多开箱即用的效果。 持久化服务的启动和运行非常容易，这带来了多个实例和主机之间的可靠性和负载分配。
另一方面，就像表单应用程序一样，工作流设计器向您推荐的代码模式很糟糕。 但是，您可以通过在工作流中不编写任何代码并将所有工作委托给其他类来避免问题，这些类可以比工作流更优雅地组织和单元测试。 然后你就可以得到设计师炫酷的视觉效果，而无需背后繁琐的意大利面条代码。
The major reason I've found for using workflow foundation is how much it brings you out of the box in terms of tracking and persistence. It's very easy to get the persistence service up and running, which brings reliability and load distribution between multiple instances and hosts.
On the other hand, just like forms apps, the code patterns that the workflow designer pushes you towards are bad. But you can avoid problems by writing no code in the workflow and delegating all work to other classes, which can be organized and unit tested more gracefully than the workflow. Then you get the cool visual aspect of the designer without the cruft of spaghetti code behind.
我目前工作的公司建立了 Windows Workflow Foundation (WF)，他们选择使用它的原因是因为规则会经常更改，这将迫使他们重新编译各种 dll 等，因此他们的解决方案是将规则放置在数据库中并从那里调用它们。 这样他们就可以改变规则，而不必重新编译和重新分发 dll 等。
The company I am currently working for set up a Windows Workflow Foundation (WF) and the reasons they chose to use it was because the rules would frequently be changing and that would force them to do a recompile of the various dll's etc and so their solution was to place the rules in the DB and call them from there. This way they could change the rules and not have to recompile and redistribute the dlls etc.
Windows 工作流像它的表亲 BizTalk 一样吸引着非编码 IT 经理、BA 等，但在实践中，单元测试、调试和代码覆盖率只是众多陷阱中的三个。 您可以克服其中一些问题，但您必须投入大量资金才能实现这一点，而使用纯代码您就可以做到这一点。 如果您确实有长期运行的需求，那么您可能需要更复杂的东西。 我听说过关于能够在不重新编译 dll 的情况下将新的 xaml 文件投入生产的争论，但说实话，工作流消耗的时间可以更好地用于改进持续集成，使编译部署不再成为问题。
Windows Workflows seduce non-coding IT managers, BAs and the like as does its cousin BizTalk but in practice unit testing, debugging and code coverage are just three of the many pitfalls. You can overcome some of them but you have to invest heavily in achieving that whereas with plain code you just get that. If you genuinely have a long-running requirement then you probably need something more sophisticated. I've heard the argument about being able to drop new xaml files into production without re-compiling dlls but honestly the time that Workflows will consume could be better used to improve your Continuous Integration to the point where compiled deploys aren't a problem.
我会在任何需要使用工作流的环境中使用它，但是当将它与 K2 甚至 SharePoint 2007 结合使用时，该平台的强大功能确实非常有用。 当与 BI 专家一起开发业务应用程序时，建议使用该平台，这通常只与简化和改进业务流程相关。
据记录，WF 是与 K2 开发团队联合开发的，新的 K2 Blackpearl 是在 WF 之上构建的，MOSS 2007 和 WSS 3.0 的工作流引擎也是如此。
I would use it in any environment where I need to work with workflow, however when using it in conjuction with K2 or even SharePoint 2007 the power of the platform is truly useful. When developing business applications with BI specialist the use of the platform is recommended and this would normally only be relevant to streamline and improve business processes.
For the record WF was developed in conjunction with K2's development team and the new K2 Blackpearl is built on top of WF, so is MOSS 2007 and WSS 3.0's workflow engines.
当你不想手动编写所有这些代码来维护可视化界面、跟踪和持久化时，投票给 WF 是一个明智的选择。
When you don't want to manually write all those codes to maintain the visual interface, tracking and persistence, it's a wise choice to vote for WF.
我已经使用 Windows 工作流几个月来开发自定义活动和重新托管的设计器，非开发人员可以使用它来构建工作流。 WF 非常强大，但它的好坏取决于开发人员构建的自定义活动。 归根结底，开发人员必须查看非开发人员构建的工作流程来进行测试和调试，但从他们可以创建草稿工作流程的角度来看，这太棒了。
此外，如果您有长时间运行的进程，当您需要动态更新进程时，WF 是一个很好的技术堆栈，无需重新安装/下载或执行任何操作，只需将新的 XAML 文件添加到目录中，您的体系结构应该是设置版本控制以废弃旧版本并使用新版本。
I have been using Windows workflow for months now to develop custom activities and a re-hosted designer that non-developers can use to build workflows. WF is very powerful but it is only as good as the custom activities that are built by developers. When it comes down to it, a developer would have to look over workflows built by non-developers to test and debug but from the point they can create draft workflows- that is fantastic.
Furthermore, in cases where you have long running processes WF is a good tech stack to use when you need to update processes dynamically - without having to reinstall/download or do anything, just add the new XAML files to a directory and your architecture should be set up with versioning to scrap the old one and use the new one.