Why use Windows Workflow?

Question

What is the benefit of using Windows Workflow foundation (WF) versus rolling your own workflow framework?

From what I can tell, WF only provides a pretty bare-bones runtime engine, a bunch of classes, and a schema (XAML-based) for defining workflows. All the hard stuff such as persistence, providing a host process for the runtime, and implementing distributed workflows (across processes) is left up to you.

Plus there is a learning curve to using WF... if we created our own workflow framework we would simply leverage skills that all developers already have (C#, XML, SQL, etc).

I saw this blog from an MS evangelist which tries to explain why we should use WF:

Why Workflow?...

IMO it doesn't do a good job of convincing because it just states that it helps "developer productivity", while admitting that developers could roll their own.

Can any of the smart folks here come up with a better reason?

SUMMARY FROM ANSWERS GIVEN BELOW:

---

I think the most convincing reason is that using a standardized workflow platform such as WF (versus rolling your own) will allow you to leverage current and future tooling such as the Visual Designer, provided by MS and third parties.

Also because it is part of the MS stack of .NET based technologies, it will likely have better integration/migration path with future MS technologies (such as Azure).

Finally, the number of developers with WF experience will increase (as it will benefit them career-wise), turning it into a basic commodity skill such as SQL or HTML, meaning it will become easier to find people who can start working with it with minimal ramp up time.

Answer 1

There is some reasonably nice designer support in Visual Studio that I'd rather not have to roll for myself, and it's a framework supported by someone else rather than me, meaning someone fixes the architecture bugs and does the main testing, leaving me to test just my workflow. I mean, I could roll my own versions of GDI+ calls, but I'd rather not. Same goes for my own serialization framework, XML parser, or some other element of the .NET framework.

When it comes down to it, these things are provided as a toolkit. Whether you choose to use a tool or not depends entirely on the problem you're solving, the suitability of the tool, and the time and resources you have available to achieve the goal.

Answer 2

I have had to create Workflow activities at my job, and I can't even tell you the answer.

One not very valid reason is that invalid values/inputs can be determined and refused at design time for workflow diagrams, and so compile-time errors basically don't exist (assuming all that boilerplate code you wrote has no compile-time errors).

Answer 3

The main reasons I can think of to lean towards using WF over another workflow framework are:

1. Microsoft is supporting it as a core part of the framework, so it can/will be easier to integrate into their other technologies like Sharepoint and Azure "cloud applications"
2. The tooling is likely to improve and be really slick in another few versions, which should improve developer productivity

Answer 4

Short answer: it's free and it gets the job done. If you can roll a better framework for managing workflow and want to spend your time on it, by all means do. But consider that your time is worth money, so how much money are you willing to commit to building a better framework for managing workflow? I could see that getting expensive.

Also, I'm pretty sure that persistence (to disk or SQL) is handled out of the box.

Answer 5

It will look good on your resume.