17
Aug
2005
On state management
As part of the conversation about MVC, Grant Skinner brought up state management. I believe having centralized state management is critical, although I don’t consider that the same thing as a controller.
Flash based apps tend to have recognizable “locations”. These may include things like a login screen or an index page. Controls may also have states, such as an “up” state and a “down” state. Using a centralized dispatch mechanism for states is a good idea. I don’t think of that as the same thing as a controller, but people seem to mean different things by the word controller…
I don’t consider that a controller either. I consider a controller the business logic of an application/screen while there will always be a different State managment class. However you could combine them in simpiler RIAs but I don’t consider that good design.
Sho — really enjoying the debate you’re stirring here. I’m also in agreement with you that state management belongs in the model, and not in the controller. To me, the controller is about dispatching work – the controller is an artefact in the implementation of the Command pattern. The Command Pattern allows me to encapsulate requests as objects, parameterise these requests, queue requests, log requests, apply security management around requests (does this user have the rights to perform this operation), etc. How to determine which command should be executed, is the role of the controller, and that determination is made in the Flex/RIA world by a user-gesture most typically. In the “Core J2EE Patterns” world-view, the “Service to Worker” pattern collaborates a front-controller with a dispatcher (the command pattern in my preferred implementation) so that we can control flow of execution, and access to business data.
I liked (in your previous post) the distinction between gestures that require model changes and gestures that require view changes, but to be honest, I’ve never felt the need to theorize to that level. A healthy dose of pragmatism, and I think I’d say that the controller/command interaction is most typically about tallying user gestures up with flow of control and access to business data.
My preference (if you have followed any of the Cairngorm implementation, you’ll understand our current thinking on how to encapsulate state and view management within a controller architecture) is that controller manages application workflow, but that the commands that perform the actual work, are responsible for updating *state* and more generally, updating the model.
Flex provides a great deal of coding idioms and constructs that greatly reduce the amount of work required to bind a view to a model; there’s no need for us to observer-type strategies in our UI, as Flex essentially does this heavy-lifting on our behalf.
So .. with a command and control tier in place, the “work” that needs to be done in application development is to manage application workflow, to integrate cleanly with data services such that we can maintain a consistent client-side model, and to ensure that our UI is well-defined to render that model accordingly.
When we start managing state within the model, it’s a no-brainer with the Navigator containers in Flex, to start rendering multiple views according to the current state/model. This removes all the complication that you cite in terms of changing your implementation of your shopping cart view, and any impact that should (it shouldn’t) have on your controller.
I think where people are blindly adopting design patterns, and microarchitectures based upon collaborations of design patterns, without understanding the context that has driven the emergence of a particular pattern, then we realise the situation Grant describes, where patterns actually limit developer creativity rather than guide it. However, with a clear understanding of the forces, contexts and solutions that various design patterns can offer within an RIA architecture, many of the fears you express, become the day-to-day pragmatic decisions that I see competent Flex developers making on an hour-by-hour basis.
The “service to worker” collaboration, is a macro collection of patterns that allows us to perform client-side authentication of requests, minimise inline code, encapsulate business logic in reusable business components, simplify complex control flow, simplify view management and ultimately provide structure to the task of managing workflow and access to business data.
With that grand vision in place, the controller and command pattern is one appropriate solution, but not the only one.
I’d like to let Flex do the heavy-lifting on the “observer” side of the view binding to the model, I’d like to let Flex do the heavy-lifting on the data services side of the model synchronising and integrating with server-side data services, and I’d like to see a little bit of regular architecture introduced to ensure that there is structure and common sense in how complex workflow and interaction is mapped to these data services.
I’ll assume I’ve won the war on code maintainability and readability, unless further challenged :-)
Best wishes, Steven.
scam thai restaurant scam a4 paper thailand thai customs scam bitcoin scam thailand
thailand atm scam https://siam-shipping.com/