When to use Windows Workflow Foundation?

Question

Some things are easier to implement just by hand (code), but some are easier through WF. It looks like WF can be used to create (almost) any kind of algorithm. So (theoretically) I can do all my logic in WF, but it's probably a bad idea to do it for all projects.

In what situations is it a good idea to use WF and when will it make things harder then they have to be? What are pros and cons/cost of WF vs. coding by hand?

It seems worth noting that a completely re-written for the 4.0 release which came out after these answers. — sclarson, Jan 12 '15 at 16:48

score 127 · Accepted Answer · edited Aug 24 '16 at 09:25

127

You may need WF only if any of the following are true:

You have a long-running process.
You have a process that changes frequently.
You want a visual model of the process.

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.

edited Aug 24 '16 at 09:25

Dmitry Egorov

9,542
3
22
40

answered Sep 21 '08 at 16:05

Panos

18,992
6
45
54

4

What is the measuring unit for long-running process? – ivorykoder Apr 20 '13 at 03:25
6

@ivorykoder "processes" (really *workflows*) that can survive restarts of the server hosting it. – lobsterism Jul 15 '13 at 01:18
If I had requirements that only satisfied #1, that wouldn't be enough for me to choose WF. However if the requirements included #2 and/or #3, that would be a much stronger case for using WF. – Mick Sep 04 '14 at 08:18
12

I can't resist: You may need WF only if any of the following are true: false. – Ronnie Overby Jan 23 '15 at 18:52

score 87 · Answer 2 · edited Mar 06 '18 at 15:02

87

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. :)

edited Mar 06 '18 at 15:02

Stephen Kennedy

20,585
22
95
108

answered Dec 21 '11 at 18:11

Ronnie Overby

45,287
73
267
346

28

-1 i respect your opinion on this but would much appriciate a professional explenation of the reason. i cant see how this kind of an answer helps anyone – danfromisrael Jan 25 '12 at 08:08
9

I wrote this answer on a day that I was angry at WF4. I'll update my answer with the issues I have faced. – Ronnie Overby Jan 25 '12 at 14:11
5

We inherited a half completed project from a consultant which used WF as its backbone. It was prone to errors, corrupted workflows that can't be restarted, an archaic versioning system that requires a complete duplicate of the workflow for any minor changes, horrific generated code, and such a delicate code that you have to handle it with kid gloves. After 6 months of yellow screens of death we scrapped the entire WF and used xml instead. Best decision we ever made. – Kevin DeVoe Aug 28 '13 at 13:35
10

The phrase: _"Doesn't provide enough power, flexibility, or productivity gain to justify its use"_ says plenty enough for me. Thank you for that. – David Tansey Oct 04 '13 at 16:20
1

Haters need to explain their hate. – Ronnie Overby Mar 25 '14 at 13:35
1

This answer is completely wrong. You should read more articles about WF and then think about your answer once again. For example: WF is easy to debug, you can set breakpoints in the Visual Designer. My opinion is: WF is very powerful, you can create a toolset for your company managers so they will be able to make changes in the business logic on their own. Then you don't even need a developer. – Sven Sep 10 '15 at 12:12
1

But I have to admit that initial version of WF 3.5 the designer was really horrible. – Sven Sep 10 '15 at 12:37
1

@Sven My opinion isn't wrong! Yours is! :P – Ronnie Overby Sep 10 '15 at 17:47
I absolutely HATE Windows Workflow Foundation. But this answer is pretty bad. – Phill Aug 16 '19 at 07:06

craigb · Answer 3 · 2008-09-19T22:16:19.477

46

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.

edited Sep 19 '08 at 22:16

answered Sep 19 '08 at 18:02

craigb

16,827
7
51
62

score 42 · Answer 4 · answered Jul 29 '13 at 11:14

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...)

Most of your disadvantages are simply not true, maybe you are not familiar enough with WF. WF is *very* flexible. It let's you write custom activities (code activities) that you can reuse in any scenario. It's up to you to write reusable activities. Imagine you would be able to provide a GUI (WPF app with Workflow Designer Host) to Business Consultants along with a toolset of activities. Now they can change and re-arrange business logic in their needs and they don't require developers and even compile a new application. — Sven, Sep 10 '15 at 12:09
Now imagine the Business Consultants have to use your self-hosted designer, but without Intellisense! Either roll your own or you have to use Visual Studio. I also think it will be difficult for Business Consultants to even understand some of the concepts such as compensation, cancellation, exception handling. Also any logic that is event remotely complex will result in a giant workflow that becomes unmaintainable (oh, and you'll need tons of ram to edit such workflows). You are right though, with carefully crafted custom activities do provide a fair amount of flexibility. — Mas, Sep 10 '15 at 14:20

score 27 · Answer 5 · answered Sep 19 '08 at 18:10

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.

score 11 · Answer 6 · edited Jan 07 '12 at 15:44

11

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.

edited Jan 07 '12 at 15:44

Paul Hadfield

6,088
2
35
56

answered Sep 19 '08 at 18:03

Rob

25,984
32
109
155

score 7 · Answer 7 · edited Sep 09 '13 at 15:25

7

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.

edited Sep 09 '13 at 15:25

rae1

6,066
4
27
48

answered Mar 30 '09 at 16:22

21

Too bad regular web services and applications don't have .config files, can't read databases, nor read XML nor local files that contain rules, without recompiling. Oh wait... – Dour High Arch Dec 21 '11 at 19:46

score 6 · Answer 8 · answered Aug 15 '14 at 05:58

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.

score 3 · Answer 9 · answered Sep 21 '08 at 18:13

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.

score 2 · Answer 10 · answered Apr 15 '13 at 08:44

2

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.

answered Apr 15 '13 at 08:44

sparksustc

83
2
8

score 1 · Answer 11 · answered Mar 06 '18 at 08:53

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.

When to use Windows Workflow Foundation?

11 Answers11

Linked

Related