3 July 2012
In a blog I recently read, Conrad Irwin extends the well known MVC pattern to a MOVE pattern (http://cirw.in/blog/time-to-move-on). While his critics of MVC meets the right point (“… but the problem with MVC as given is that you end up stuffing too much code into your controllers …”) I cannot see what MOVE does better. It seems to be slightly more complex - and that’s what I would criticize.
What if we simplify things? All we need to get a separation of UI from data and processing in a stateful application are Views and a State Machine. And that’s all what MVC already is in its very core. We have a state machine with transitions initiated by events from the outside world and some kind of frontier or surface or membrane between that world and the state machine. That surface is what we know as View.
The view is a window into state with a given perspective. Not all may be visible through a given window, some state may be hidden, but moving over the surface will expose all state eventually. At some points at the surface we have sensory cells (those buttons) firing events into the state machine when touched, causing transition. And that’s what most MVC applications already do.
The perception of burdened controllers (and often views as well) is in essence caused by the fact that they simply doesn’t exist. Partly they are elements of the “M” - for Machine, partly elements of the “V” for View. And if you want a clean architecture based on a well understood computational structure, all you have to do is to accept the fact of having a State Machine and Views of state and nothing more.
BTW I willingly omitted the “F” of the (F)SM since this might be subject of discussion here, despite the fact that “infinite” is really huge in the world of computation.
Powered by Tumblr; designed by Adam Lloyd and Ingo Schramm.
