Workflow Design Dilemma - State Machine, yes or no

Question

I'm a beginner with WF, but I've read a book and done a lot of googling. I want to write an inventory management service. The inventory is made up of individual items which have a state:

Spare
Installed
In-Repair

Items may spend months in each state, and there are thousands of items.

The question is, do I create a state machine workflow for all the different states? Or do I create workflows for transitioning between states?

If I understand correctly, if I create a single state machine workflow, then there will always be a workflow running for every item. This means thousands of ever-running workflows. Also, I need to be able to display a snapshot of the status of each item, so that means I have to somehow query all the workflows for the state they are currently in, or otherwise persist to a database after each state transition.

However, a state-machine workflow logically sounds like the right thing to do, hence my dilemma.

Please help me if you can :-)

Thanks!

Update:

Assume I have more states than the above 3, and that not all state transitions are possible.

Bounty Winner: Maurice - Thanks to everyone else for really helping me understand more about workflows, the MS workflow foundation, and other more lightweight alternatives. Unfortunately, there can only be one bounty winner, and Maurice's answer along with its comments helped me the most.

I'm no workflow wizard, but as an architect I would seriously question your approach to model inventory item states with a workflow engine. Or maybe I miss something. What do you use the workflows for? — TToni
The 'meat' of the workflows lies in the transition between states, where I need to validate my business logic. For example, when transitioning between Spare and Installed I need to make sure that the installation location is vacant first, then I have to change state, and then I have to notify logistics about the installation, etc. — Aviad P.
OK, so you need to execute some business logic when an item changes state. But I still don't see why you would use WF to do this. I assume you store the current state of each item in some database anyway. If you don't and there are other good reasons to use WF, then having one WF instance for each item looks like the better alternative to me. But if the state transitions of the WF only reflect the item state transitions, then you just end up storing the item state in a complicated way (as persistent WF instances instead of some database column). — TToni
What you're saying makes sense, but then can you think of anything that would make this scenario better suited for a state-machine workflow? - Also, using a workflow (state machine or otherwise) is a good practice in and of itself, it makes the flow of execution much more clear. By not using a state machine workflow, some of the process is obscured in code. That's part of my dilemma. --- Good night TToni :-) — Aviad P.
I still don't feel that WF instances are the right tool to capture your inventory item states. If you have non-trivial logic that you want to capture in a WF for item state transitions, that's fine, but why not use a different WF for each transition, instead of one big WF that includes the inventory item states? You can still use a process model diagram to explain your overall logic, but you don't have to capture everything in a WF model. If someone runs into problems like yours then it's 99/100 times an indicator of using a component in a way it's not meant for. — TToni

David Robbins David Robbins · Accepted Answer · 2009-12-30T12:45:32

A state machine is a very powerful technique to implement, although I would recommend that you consider a framework called StateLess by Nicholas Blumhardt (Autofaq creator), as it is an amazingly simple implementation of a state machine that avoids the unnecessary complexity of Windows Workflow. His approach avoids the issue of long running workflows being held by a runtime engine, as the state is defined by a simple variable such as a string or int.

Here is a sample state machine:

var phoneCall = new StateMachine<State, Trigger>(State.OffHook);

phoneCall.Configure(State.OffHook)
    .Permit(Trigger.CallDialed, State.Ringing);

phoneCall.Configure(State.Ringing)
    .Permit(Trigger.HungUp, State.OffHook)
    .Permit(Trigger.CallConnected, State.Connected);

phoneCall.Configure(State.Connected)
    .OnEntry(() => StartCallTimer())
    .OnExit(() => StopCallTimer())
    .Permit(Trigger.LeftMessage, State.OffHook)
    .Permit(Trigger.HungUp, State.OffHook)
    .Permit(Trigger.PlacedOnHold, State.OnHold);

// ...

phoneCall.Fire(Trigger.CallDialled);
Assert.AreEqual(State.Ringing, phoneCall.State);

Your state can be an integer which will allow you to feed it the current state from a database. This can be set on the constructor of the state machine as follows:

var stateMachine = new StateMachine<State, Trigger>(
    () => myState.Value,
    s => myState.Value = s);

You can implement this in just one assembly, compared to the multiple projects you need to run Windows Workflow. Maintenance is extremely low, their is no "designer" that generates code for your, etc. Again, it is simple, and there lies the beauty.

Workflow Design Dilemma - State Machine, yes or no

9 Answers