Workflow Foundation suitability - duplicating stored information

Question

Despite going on a training course for Workflow Foundation earlier this year, I recently abandoned an attempt to use it in a project because there were just too many compromises to get it to work. There are few extension points (everything is sealed, and the mechanisms for getting data/events into and out of a workflow instance are just the opposite to the pit of success), and generally it's just hard to plumb it in.

My main issue is that if I use a state machine workflow, I then also have to persist state in my database. This causes me trouble keeping the two in synch.

The example is a bug tracking application. Each bug would typically have a status column, and that can be easily queried and reported on. However if you introduce WF, I never really understood how to plumb it in so that the workflow state updates the database record's state etc.

Does anyone else have a view on this? In the end I've implemented my own bespoke database-based workflow system, where each status has a list of possible "next" statuses, and each status has a number of people/roles it can be assigned to.

Answer 1

Programming your own workflow gives you more controll, but at the same time creates more work for you.

If you are working in a team it is possible to hire a new person that knows windows workflow, but no new hire will know your bespoke workflow.

We have implemented systems both with windows workflow and where the workflow is simply C# code. Our main problem with windows workflow has been the performance, the main benefit is the controll it gives in very complex situations. You can show the workflow diagram to the customer to verify that that is what he meant.