PureMVC

Horatio - O day and night, but this is wondrous strange!

Hamlet - And therefore as a stranger give it welcome. There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy.

-- Shakespeare's Hamlet (I, v, 166-167)


When Alan Kay began work in the early 70's on what would become Smalltalk-80 (the birthplace of MVC), there was a fundamental difference in the focus of applications they were writing then and the ones we are writing today.

In his 1987 text; Applications Programming in Smalltalk-80: How to use Model-View-Controller (MVC), Steve Burbeck puts it like this:

One of the contributions of Xerox PARC to the art of programming is the multiwindowed highly interactive Smalltalk-80 interface. This type of interface has since been borrowed by the developers of the Apple Lisa and Macintosh and, in turn, by the Macintosh's many imitators. In such an interface, input is primarily by mouse and output is a mix of graphic and textual components as appropriate. The central concept behind the Smalltalk-80 user interface is the Model-View-Controller (MVC) paradigm.

Although Kay did go on to develop prototypes of networked workstations using Smalltalk, they were by and large, writing windowing applications that read and wrote synchronously to local storage.

In a late-model RIA (Rich Internet Application), there is an extra and rather cumbersome concern, which is that of communicating, usually asynchronously, with remote services as part of the application's domain representation.

Therefore, a completely 'purist' implementation of MVC today would still leave a giant question unanswered: How do we deal with services?

One option is to consider Services an entirely new actor in the pattern. Joe Berkovitz gave an interesting presentation at Adobe MAX 2006 outlining what he terms an MVCS, (Model-View-Controller-Services) approach.

That's a tempting idea, but the collaboration patterns for the Controller become rather involved, since it must now have deep knowledge of both the Model and Services.

If we are not introducing a new actor (not to mention getting a new website and project name...) we must consider the responsibilities introduced by communication with services and how to divvy them out to our classic actors.

In an RIA, the client maintains the state of the application, and the representation of state is classically held in the Model. I have not, as yet, seen compelling reason to believe that responsibility should be moved elsewhere (or shared by another actor) in a stateful client.

But since the Model is classically a 'passive' actor, (typically a graph of objects, observed by the View and updated by the Controller) it seems natural to consider the burdon of communicating with services a responsibility more suited to the Controller.

This approach is taken by the Cairngorm framework. In order to support the new complexity of the Controller's slice of the MVC pie, it brings 2 key patterns from the J2EE world (Business Delegate and Service Locator), to abstract away the actual location of services and their APIs as acted upon by Commands.

This still leaves us with a somewhat lopsided triad.

The Controller is now a large and complex region of Commands that respond to user events, as well as lookup and communicate with Services through a Business Delegate and the View through a ViewLocator

The View is busy enough representing the Model as well as fielding user events and routing them to the Controller, (a region in its own right, encompassing EventDispatcher, ViewHelper, and ViewLocator actors)

Yet the Model remains somewhat amorphous and undefined bag into which we place things, acted upon by the Controller and View.

View and the Controller are both deeply coupled to the Model. The View must know what region of the Model it wishes to represent, and the Controller must assume intimate knowledge of the Model regions it wishes to manipulate.

This means that while we can change the presentation (View) and business logic (Controller) independently of each other, we cannot easily change the internal Model representation without substantial refactoring of both the Controller and View implementations.

I don't know about you, but it looks to me like its time for the Model to get a job and start paying rent.

-=Cliff>