Drinking the Framework Kool-Aid

I'm lucky enough to have a job where I'm afforded a bit of R&D time, every now and then. Currently that entails evaluating various Flex frameworks, which will eventually impact some architectural decisions being made down the road. That being said, I must confess that I've traditionally not given a lot of credit to frameworks, preferring to drink the homebrew code cocktail that I mix up myself. That trend may be changing, though. I've come to accept that all of these frameworks and accompanying design patterns really strive to address legitimate concerns. However, it seems to me that for the most part, they end up creating a whole new set of problems of their own. So, currently I'm on the fence. Here's what I've discovered:

Cairngorm is an under-sugared, bitter-tasting Grape ...

First, there's simply way too much boiler-plate code involved. One can argue that this is great for development pattern enforcement in enterprise environments where 80-bajillion programmers are all working on the same set of functionality, each from a different angle, but I disagree. Although segmentation is important, I don't think these divisions of labor pay off in an enterprise environment as well as people claim. Honestly, I tend to think of the enterprise development as synonymous with "slow," as all of my anecdotal experiences have taught me, despite having very clean, ideologically correct code abstracted out the wazoo.

Second, Its abundant use of singletons with the Model Locator pattern and no clear mandates of when to pass data down a view hierarchy or just hit the singleton, short of "use your best judgement," seems wrong to me. I know for a fact that excessive singleton usage hurts unit test capabilities, modularization (literally, Flex modules), and the ability to debug without wanting to drop-kick your laptop.

Finally, for the first two reasons, Cairngorm enthusiasts remind me of those crazy religious zealots who like to flagellate themselves out of some twisted sense of duty. I may drink the kool-aid, but I don't want to join that camp, thanks.

PureMVC is the somewhat questionable Tropical-Punch ...

Looks like PureMVC aims to alleviate developers of several of the common-complaints Cairngorm brings about. That's admirable, as is the goal of being ECMAScript compliant, rather than being ActionScript specific. However, in my initial glance, I'm seeing a lot of the same boiler-plate, only with more patterns at play, such as Proxies, Mediators, and Facades; all of which I have no real clue as to their intent. I suspect they're there to be unnecessarily confusing. I really need to learn up more and until then, judgment is reserved.

Joe Berkovitz's MVCS Blueprint is Cherry awesomeness ...

This should be considered more of a set of guidelines, rather than a framework, as there is no real distribution or official repository of documentation. That being said, there are a few things I can really appreciate about these patterns.

For one, the use of singletons is throttled to Controllers, Services and Session information. This just flat out eliminates the majority of problems a developer can encounter when exposing their Model in singletons. However, rather than having to pass reference down from a top level controller to a particular View, the View is allowed to directly ask for data from the Controller ...

Controller calls that require asynchronous interactions accomplish this with what some people have termed the Future Value Pattern (or just Futures). In this scenario, you construct a placeholder for your data in your Controller, pass it by reference to your Service call, then immediately return it. At some point, your asynchronous call will return to populate that reference, leaving your view to listen to bindings and update your UI. Very clean, very accessible, no unnecessary Event bubbling. This in itself helps to reduce a significant amount of boiler-plate.

Finally, Joe preaches the use of dependency injection with a base class that referenes Controller and Service interfaces, then a subclass which implements those via MXML. Think compile-time Spring IOC. This opens a lot of doors when it comes to developmental mocking, testing, and easily adapting code.

Those are my initial thoughts ... I plan to spend a good bit of time on this subject.

Edit: Here's a good presentation on frameworks by the developers of ASUnit. Definitely worth a watch if you're a total dork.