Putting the MOVE framework in proper perspective

In a recent post, on data models and persistence, I made what I now realized to be a pretty fundamental mistake: I talked about the use of data models in web development, but I restricted my discussion to MVC-style frameworks alone and should have said more about alternative design patterns.

I restricted my discussion in this way more for the sake of brevity than anything else, but I’ve learned a lot in the last few weeks about alternative architectures and want to begin weighing in. Next week, I will discuss Knockout.js’s MVVM (model-view-view model) front-end architecture and the abstraction gains associated with it. But first, I want to discuss another alternative to MVC that’s been getting a lot of traction on the webs in the last few days: the MOVE framework, as outlined by Conrad Irwin.

MOVE is an (admittedly quite clever) acronym for Models-Operations-Views-Events. What the term seeks to capture is an emerging way of structuring applications that doesn’t rely on an explicitly defined and coded controller. The problem, according to Irwin, is that quite often “you end up stuffing too much code into your controllers, because you don’t know where else to put it.”

A much better way of doing things is to divide your controller up into two distinct elements: (a) operations, which are induced by (b) events. Operations include “everything that your application does,” while events are defined as changes–such as mouse clicks, the creation of new instances of a class, and so on–that call for an operation.

In Irwin’s schema, the conceptualization of models and views remains more or less the same. It’s only the controller that demands fresh thinking. Why? Because an event-driven framework is one in which event-operation pairings cannot be explicitly defined in an isolated area that then supervenes upon the rest of the application. Event-operation chains must be defined “on site,” so to speak. They’ll be scattered throughout your application’s code, and you won’t have a way of managing them all from a single file or directory.

The controller in the MOVE framework is thus thoroughly conceptual. It’s an emergent property of the way that operations respond to events. There is no “place” in your app’s structure that could rightfully be called “controller” (as in Rails, where controllers are quite explicitly defined and by default attached to class-based data models).

I appreciate Irwin’s argument because it’s not for or against any particular language or framework. Instead, it’s an attempt to re-frame our thinking about application structure in light of recent developments in web dev.

As Irwin himself readily admits, there is nothing “wrong” with MVC. In fact, MVC is “awesome” but suffers the misfortune of being “designed with decades-old technology.” The MOVE architecture is inspired by the attempt to “make better use of the new tools we have,” presumably including things like “thick” client-side architectures and non-blocking servers.

Irwin’s article makes a number of good points, and I appreciate his attempt to think beyond MVC application structure in a way that seeks to account for major shifts in web development. But I still see the MOVE framework as being more of a reconceptualization of application architecture than anything else.

There’s nothing wrong with reconceptualization. This can often enable developers to re-think their current projects or to embark upon projects of which they wouldn’t have been able to conceive previously. But a conceptual alternative is not a “real” alternative, the way that, say, Ruby on Rails provided a real, fleshed-out alternative to .NET development or the way that Node.js provides an alternative to Tornado or Eventmachine.

But this state of affairs could change. After all, MVC architectures existed long before web development came along and made use of the design concepts bound up with MVC. Thinking in MOVE-like terms could inspire future frameworks to rethink how we conduct web development across lots of use cases. Time will tell. In the meantime, there’s no need to “ditch” MVC or to stop using this conceptualization in places where it really, truly works.

At most, there might be room in some of your projects for a more MOVE-oriented way of grasping what you’re already doing. The rhetoric that “MVC is dead” is more provocative than anything else.

But I’d love to hear what you all have to say about this issue. I have a hard time swallowing the argument that MVC is “dead,” and my hunch is that many of you would agree. But could MVC be in need of some fresh thinking? Is MOVE-style thinking an important spur to re-conceptualizing the way we do things?

Let me know your thoughts, Dear Reader.

Share this post

Try AppFog: The new PaaS Hackers love