"Bernard of Chartres used to say that we are like dwarfs on the shoulders of giants, so that we can see more than they, and things at a greater distance, not by virtue of any sharpness of sight on our part, or any physical distinction, but because we are carried high and raised up by their giant size."
-- John of Salsbury's Metalogicon, (1159 AD)
"I can see for miles and miles."
-- The Who
Software developers are creative people. And, I believe, it is this very aspect of our nature that causes us to write our best (and worst) code. It often helps us to 'think out of the box'; to come up with clever solutions to hard problems that are not obvious. Unfortunately, it also causes us to occasionally 'reinvent the wheel'; to waste time coming up with new answers to already well-solved problems.
For the last few years, I've been architecting and/or building large-scale enterprise applications in Flex. Where I had anything to say about the architecture, I have chosen or advocated Cairngorm every single time. The authors refer to their work as a 'microarchitecture'. It is a group of classes adapted from design patterns familiar to the J2EE development community.
Coming from an enterprise Java background where design patterns rule the day, yet having made a big ball of spaghetti with my first Flex app despite
all that, I was pleased beyond words to discover a framework for developing rich clients that let me simply focus on the business at hand. Once the 'Cairngorm way' was understood, then it was possible to really get on with it.
However, I noticed a somewhat disturbing trend. On more than one occasion, I showed up at the client's site, created a Cairngorm-based prototype - not throwaway code, but intended to be 'inflated' by their developers into the actual production application, only to come back or hear six months later that they'd thrown it all away and started from scratch. Not because I left them with bad code, but because they were not able to grasp the 'Cairngorm way', and all applications are, of course, due to ship yesterday. With pressure to deliver, often brute force rules the hour and overshadows good sense. No time to learn, we've got to ship
Needless to say, this leads to the same problem I had with my first Flex app. Maintainability and scalability are right out. You can always burn down and rebuild later, right? Having been in that spot myself, I may not sympathize, but I do empathize.
, I tired of the ongoing releases and all that keeping up entailed. First the package was 'com.iterationtwo.cairngorm
', then it was 'org.nevis.cairngorm
', now it's 'com.adobe.cairngorm
'. First the ModelLocator was simply a marker interface reminding us to make a class with a bunch of static members that we could access from anywhere. Now it's a Singleton. First we were advised to use the ViewHelpers and ViewLocator, but no firm guidelines about just how much or what code should go into them. Is one ViewHelper per view component really necessary? What if you need multiple instances of the same ViewHelper? Then word was, maybe we shouldn't rely on them so heavily. Another release made some dependencies on Flex Data Services, and now, realizing that everyone might not use FDS, those bits have been extracted out to something called 'Cairngorm Enterprise'.
This post is definitely not meant to be a Cairngorm-bashing session, but rather to make clear some of my motivations for creating PureMVC. I realize there's already a wheel out there, but damn it, this is the new millenium, and I want a Hovercraft.
So, where it comes to standing on the backs of Giants, I must tip my propeller beanie and give props to the aforementioned esteemed individuals and their admirable work. It was only from the perspective that Cairngorm afforded with all its strengths and weaknesses that I could see this solution off in the distance, beckoning, asking to be built.
I wanted something that helped achieve the separation of coding interests that the Model-View-Controller 'meta-pattern' suggests in a clearer fashion. MVC has been around for sometime, surviving the rise and fall of many platforms, languages and environments. Yet, unlike design patterns that state clearly the roles, responsibilities and collaborations of the classes used to solve their problems, there is no specific prescription for implementing MVC. So that much I had to devise myself after quite a bit of survey of the prior art. See my previous posts regarding this process.
As artsy and creative as I'd like to think I am, in reality, I'm a pretty literal-minded guy. I like things to be straightforward and understandable. So the Core actors of the PureMVC framework are, predictably: Model, View, and Controller. They are all Singletons whose primary responsibilities are to cache instances of the classes that do the actual work of their respective realms.
The other classes of the framework all stem directly from the fabled 'Gang of Four'