I wanted to seriously question the current approach for declaring state machines in code using the StateMachine<T> class and IState/IStateMachineProvider interfaces (Predefined State Transitions Created in Code) and hear what you think of it in general. The main reasons behind this interest are the limitations this originally implemented approach has compared to other available solutions and hence associated support costs.
"Yet Another Controller"©
In fact, in certain scenarios, creating a custom Controller with the SingleChoiceAction Action or a set of SimpleAction Actions can be simpler and more straightforward than defining a coded State Machine at a domain level. To give you a concrete example of such an alternative solution, check out this Controller that eventually does the same thing as the code in the original documentation article above, but with old-good SimpleAction objects manipulated on View and other suitable events. You can find another example with a SingleChoiceAction in this test project (process it with the Project Converter tool first). Even though the alternative Controller-based approach requires more code, it allows you to provide a more granular control over created states and their visual representations. It is cleaner and easier to understand/extend for other business requirements, because it is your own code that uses only the basic XAF APIs.
Implications of using the questioned approach
Contrary to that, the questioned approach is really a bit shorter with the help of 'state', 'transition' and 'state appearance' abstractions defined near your business class, but everything has its own trade offs.
Contrary to that, the questioned approach is really a bit shorter with the help of 'state', 'transition' and 'state appearance' abstractions defined near your business class, but everything has its own trade offs.
First, the aforementioned abstractions provide only common options that make accomplishing non-typical customizations harder than operating with Actions directly. For instance, you will have to understand the structure and override specialized StateMachineXXX controllers defined in our module if you need to modify the default behavior and visual appearance of the Action items created at runtime based on the state and transitions structure. Another complexity is that our default StateMachine module code is quite generic and updates the Change State Action on various events, which may be unnecessary in your specific scenarios and can even cause unnecessary overhead sometimes.
Our current conclusions
As you might distill from this, our position developed after several years of module maintenance and digesting a lot of user feedback: the Controller/Action-based solution can be and should be considered in the first place instead of using the State Machine module in a good number of scenarios, especially if you need to define a fixed state management process/structure that should not be changed by end-users. So, we are also thinking of not showing the original approach in the online documentation and demos for new XAF users.
Your thoughts are welcome!
Please let me know what you think about the points I made above and tell more about your own experience with this module. In particular, which approach you are favoring more for state management:
1. configuring built-in abstractions for states, transitions, etc. in code;
OR
2. creating Controllers/Actions and managing their state manually.
?
?
I will also be eager to hear about things that you think deserve more attention in the StateMachine module. Thanks for your answers in advance!