When to use Windows Workflow Foundation? [closed]

Answer 1

Never. You will probably regret it:

• Steep learning curve
• Difficult to debug
• Difficult to maintain
• 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. :)

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.