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:

1. Spare
2. Installed
3. 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.

Answer 1

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.

Answer 2

Not sure if a workflow is what you are looking for in the first place.

A workflow is some kind of business process that takes place. This implies a beginning and an end to the process. Your description sounds more like you are tracking an inventory of sorts with items that stay in the inventory.

A workflow sound more appropriate when an item changes state. For example when an item is installed and breaks down and needs to be fixed you would start a workflow to get the part replaced by a a working one, send the broken part to be fixed and in the end have it back at the warehouse as a fixed spare. The workflow would describe this process and start with the report of an item being broken and end with the item being either repaired or discarded and replaced.

This last workflow could very well be a state worklfow as the item goes through various stages like:

• Broken and installed
• Broken and replaced
• In the shop for repair
• Repaired
• etc