Comparison between Stateless (on google code) and Windows Workflow
I'm starting to think that I should ditch Windows WF in favor of something simpler. I don't necessarily need to pause workflow execution for extended periods of time and restore them later. I would like a simple state machine framework that does have basic suspend / resume / abort (without serialization), however.
I've downloaded the Stateless framework from Google Code and am going to start playing with it, but would love to hear what the other .NET programmers out there are using.
EDIT Stateless seems really simple to implement, but I do wonder if it's the right thing for a candy machine. In automation, I always feel conflicted about how state machines should be used. Although I use the term "state machine", I do so loosely because I use it more like a flow chart. Instead of using states to represent the current mode a machine is in, I use it to execute functions. So in this case with Stateless, I'd actually be using the transition from one state to the next as the mechanism for calling functions in my candy machine's controller. Thoughts?
Answer
As I work through this, I'll try to list some of the things I'm finding. Most will likely be a bit superficial from an analysis standpoint (especially since I'm new to both frameworks), but hopefully it will help someone out.
Stateless
Pros
- open source
- syntactically concise and easy to read
- pretty good examples in the mercurial repo on google code
- I can translate my UML state diagram into code using stateless very quickly.
- state maintenance is very simple -- I can add and remove with ease. Extension methods allow me to configure the states on separate lines, so I can comment out the triggers or actions that I don't want to use.
- passing data to/from state machine is easy and you can do it however you wish in code-behind.
- likewise, state machine can update GUI in a variety of ways. Right now, I'm modifying data via an interface, and then the GUI uses a timer to update its elements. I could also probably use a BackgroundWorker to do this.
- I've just started to use substates for handling my GUI, which needs to manage various states like Running, Paused, Aborted, and Idle. The Paused state has substates because the user can pause the system in a variety of ways, but the resume triggers are specific to the way in which they were paused. I love being able to manage my GUI's enabling / disabling and tooltips by using a lightweight state machine framework.
Cons
- no built-in mechanisms for pause, resume, abort
- only one developer supporting the project. I did get assistance with a problem I recently ran into, however.
- potential for misuse if you're not careful. I implemented the state machine framework improperly on my first attempt. It worked great for months, and then eventually it died when I ran a very long-running process. It turns out I was causing the state handlers to stack up and I had a stack overflow condition.
Windows Workflow Foundation
Pros
- graphical approach to designing the workflow
- support persistence, pausing, resuming, aborting workflows
- MS probably has a big team of programmers to support this
- GUI makes it really easy to disable / re-enable activities
Cons
- graphical approach to designing the workflow hides the fact that this thing is pretty complex
- in order to use persistence and get pause / resume / abort, you have to install and set up a "persistence service", something I've yet to figure out how to get working. I can set up the SQL database fine, but at runtime I get a bunch of errors I don't understand.
- because it's from MS, you don't know if it'll be around very long or get completely dropped.
- error handling is a little weird because you can either use code behind or a FaultHandler
- passing data from WF to your main app is complicated and requires something like WCF (another technology I don't have enough time to learn adequately right now), or use the ExternalDataExchange interface.