When to use Windows Workflow Foundation? [closed]

Answer 1

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

1. You have a long-running process.
2. You have a process that changes frequently.
3. 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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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