In short the ability to “go back” during the flow is what differentiates state machine workflow from the sequential
If you dig deeper look at the attribute of a state machine flow
1. The sequence is not predetermined - The entity can go from one state to any other state based on external events
2. An event can result in no state transition also
3. Who controls the flow the user or the workflow itself. If user can make a set of choices that can lead the entity to different states then it is the user who controls the flow.
Sequential workflow can also have branches and loops but they are less complex and well laid out.
If the question is can’t I just use sequential everywhere if I am smart enough to handle yes you can, probably you will succeed also but the ROI is poor. To quote Dave
“The Sequential workflow, of its nature, encodes all the possible sequences of behavior in its structure. But here [State machine], we don’t care. We only need to know about the current state, and what can be done next. So if we spend time modeling routes through the process, event though we don’t in fact care about them, and these routes are many, as they are in the bug problem, then the Return On Investment from the Sequential style inevitably becomes very poor.”
http://blogs.msdn.com/davegreen/default.aspx
It looks like we will use state machine most often than sequential considering that most business cases are reasonably complex.
No comments:
Post a Comment