FrameworkQuest 2008 Part 6: The Exciting Conclusion

Posted on: January 16, 2009

FrameworkQuest Part 6 by Tony Hillerson
Find the original post here

FrameworkQuest 2008: Introduction
FrameworkQuest 2008 Part 2: Get Control with Cairngorm
FrameworkQuest 2008 Part 3: Agnostic Views with PureMVC
FrameworkQuest 2008 Part 4: IoC With Swiz
FrameworkQuest 2008 Part 5: Mate, the Pure MXML Framework
FrameworkQuest 2008 Part 6: The Exciting Conclusion

Well kids, it’s been a wild ride. We’ve looked at five
implementations of a simple Twitter client built with no framework, Cairngorm,
PureMVC, Swiz, and Mate. We’ve talked about important things like pronouncing
the framework’s names, architectural patterns, Inversion of Control, and
programmer joy.

In this last part, I’m going to turn off any semblance of
objectivity and let you know what I think about these frameworks. If you’re not
interested in what I think, I don’t blame you, but I also don’t want anyone to
take my word for it and blindly choose which one I like. Take a look at the
examples and see which one you’d rather work with. Come up with a simple
application and build it four different way. In other words, try before you

Ok, here we go. First, in prose, and then with some numbers.


As I mentioned early on, I’ve been using Cairngorm for a while
now. Does that make me want to stick with it or try something new? Well, I’ve
liked using Cairngorm. I also like to use Christophe
‘s  Prana
to help out a bit with sequences of commands and IoC. In fact, I wanted to have
an article on Prana

in this series, but I just ran out of time. You can settle for this blog post about delegate factories, which shows
how we might have made our dummy data solution a little more palatable.

The thing I like most about Cairngorm is the command pattern. I
really like having commands that are named with a description of what they do,
and I really like that everything to do with getting that specific task done is
inside the command.

Cairngorm, though, being around the longest and the loneliest,
has attracted criticism. It’s surprising to me, because I think it’s not a bad
framework, and not even that heavyweight. Even so, I came into this article to
try out these other frameworks and see if one struck me as something I’d rather
work with from day to day. Let’s have a look at some criticisms.

Some people don’t like Cairngorm’s verbosity when it comes to
defining a new command. I don’t think there’s anything wrong there that can’t
be solved with some code generation, but I agree that it’s pretty

Other arguments against Cairngorm are usually leveled against its
use of a Singleton model. A Singleton makes unit testing hard, and sometimes
people say it’s just a glorified "global variable". Let’s take these
one at a time.

Singletons are not "global variables". People make fun
of using global variables because it’s a rookie way of getting around building
a good architecture. It was the way we built Flash apps before we knew how to
program. That’s true – global variables are unsafe because there’s no guarantee
who’s accessing and changing them. In short, there’s no encapsulation. But with
a Singleton, there is encapsulation, because what you’re dealing with is still
an object. There’s nothing stopping you from using read-only getters instead of
public properties.

Singletons do, however, make it harder to unit test, because a
simple test that, say, runs a command sequence and tests that a property on the
model changed as expected, changes that model instance of which there is only
one. The more tests, the more the model gets into a strange initial state. I
think that’s not that big of a deal if you just take the time to reset the
model to a known state before each test. If you have to have a “logout” in your
app anyway, you’ll need to do something like that anyway (unless you cop out
and just refresh the page with javascript). I agree, though, that it’s extra
code to maintain.

One last problem people have is that Cairngorm has you putting
Cairngorm events on the view. That means you have to make a Cairngorm event,
first, and second it means that you have framework code on the view that makes
it hard to refactor away from Cairngorm.

Now, look. How many times in an app do you just scrap it and
switch frameworks? I never have. I agree that componentizing is great when you
really have a view you can turn into a blackbox component, but if you have a
view specific to a certain app I really don’t see that it’s anything but bikeshedding
to try to make the view code re-usable. There’s a point of diminishing returns,
and at that point or even a little before, you should just move on and get the
app done. That’s why I don’t care that much about Flex framework code in a Flex
application. I’m certainly open to the idea of using regular Flash events,
though, so that brings us to PureMVC.


One way I describe the difference between Cairngorm and PureMVC
to people is that Cairngorm doesn’t have much to say about your view code, and
PureMVC doesn’t have much to say about your service access code. That’s why you
see the BusinessDelegate pattern in PureMVC and Cairngorm – because it works

What PureMVC tries to fix, though, is having the view cluttered
with PureMVC code. It fixes that well – the only place you have to put PureMVC
code is on the root application. As far as that goes, I like using Flash events
instead of Cairngorm events. What’s nice there is that if I’m using a blackbox
component that emits Flash events, I can still easily respond in a Mediator
whereas in Cairngorm I’d have to catch and re-dispatch an event as a Cairngorm
event if I wanted to take action.

One other important PureMVC goal is to be an Actionscript
framework, not a Flex framework. That means I can’t (or shouldn’t) use Flex
binding to wire up a view to a Proxy, I need to have the Mediator do it. Is
that a win? I think binding is great, and I also think it needs special
understanding to use it correctly. In a medium to large sized application, by
using binding right out of the box, you can cause a really huge event storm
whenever any bound property changes and bring performance to a halt.

I think binding is good when used responsibly, so when PureMVC
says to skip it, I’m interested, but I want to know what it costs to use. So
what I don’t like about PureMVC is how much boilerplate code there is. I like
the idea of a mediator for views, but there is so much set up to do. The
constants, the viewComponent
wrapper, listNotificationInterests,

there’s a lot of stuff it takes to set up a Mediator. I like PureMVC in
general, but I’ve never gotten up the energy to use it on a project because of
inertia. It feels like it’s a big investment to do things the PureMVC way.

Contrast that with the lightest weight framework, Swiz.


I have to be honest, when I wrote this article because of the
buzz and Laura’s presentation at 360 Flex San Jose, I
was really prepared to like Mate hands down. (BTW, here’s Chris’s presentation). When I
started using Swiz, though, I immediately felt the joy. You know what I’m
talking about – that sense that you’re in the groove and building something and
there’s not much work between having an idea and implementing it.

I’m going to make a distinction that I haven’t heard before, or
at least don’t remember hearing. I think there are proscriptive and prescriptive tendencies to software
frameworks. On the one hand, proscription means saying what you can’t do, and
on the other, prescription means saying what you could do. Whereas PureMVC says
a lot of things you shouldn’t do and some things that you can do, Swiz almost
completely sticks to saying what you can do.

Swiz leaves a lot up to you. All it does is provide some easy
ways to do things like inject a controller or a model into the view and to
easily wire up events with the Mediate metadata tag. From there on out, it’s up
to you. Swiz is the laissez faire framework, and I really like that.

The only thing is that all the service interaction stuff, the
dynamic delegates and command all expect you to be using RemoteObjects and
delegate methods that return AsyncTokens. I’m sure this could be fixed, but
unless I’m missing something until it is fixed Swiz is less useful to anyone
not using AMF services. Since I’m used to using RubyAMF,
that’s great for me, but I can’t always count on it or BlazeDS or ColdFusion
being on the server side. You can work around it, but it’d be nice to have
those tools available for other types of services.

One thing I’d also like to see is an easy way to use the command
pattern where logic is actually written in the commands. I really like that
pattern because I think it’s cleaner to have logic in commands instead of in
controller files that have to do with more than one type of data or view.
Controllers tend to get a little big, especially with callbacks.

That said, I really like Swiz and I think Autowire and Mediate
are enough incentive to use it over Cairngorm or PureMVC. Swiz is the style of
programming that those three frameworks represent done right. Mate, however, is
a different, hmm… what should I say… cup of tea?


Mate is picking up a lot of steam lately (these puns are going to
keep on coming, people, you may as well just laugh now). Everyone I talk to lately
loves it. I think it’s a shame that some of those people aren’t really getting
a chance to try Swiz too, but when you feel what it’s like developing with
Mate, you’ll see that it’s not that big of a shame.

The way I make a distinction between Swiz and Mate is that Swiz
is the Cairngorm style done right, while Mate is a completely different style.
The big difference, I think, is the declarative versus programmatic style of
Mate. Since a lot of what we do in Flex is in MXML, using MXML to set up framework
interaction makes a lot of sense, and also just seems to really fit alongside
the view code.

PureMVC and Mate both want you to use regular old Flash events
instead of framework prescribed events. Swiz wants that too, but sometimes you
need to dispatch through its dispatch system. What makes Mate so elegant,
though, was the insight of just using the event-bubbling to catch them with the
EventMap without defining a bunch of wiring code. Of course, that breaks down
when you want to use a service delegate and have to pass in the dispatcher, but
it doesn’t break down as hard as Swiz breaks down when you don’t use

Mate is also really flexible. There are probably more tools there
than you need, and not only that, it has a plugin
. I don’t understand it yet, but that’s kind of nice. I
also like that Mate has a way of using Commands, although I’m not sure it would
be worth it to just turn your EventMap into a Cairngorm FrontController.

I like Mate a lot and I can’t find anything to pick on. Really.
The only thing is I don’t think I fully understand how it scales, and the way
it does view and object cacheing is a little bit of magic. Magic isn’t bad, but
again, I just don’t know what pitfalls await me while using it. I hope to find
out, though, and I’m really excited to use Mate.

Framework Smackdown

Now is the time when I give you my subjective rating system to
give a bit more quantification. Below is a table rating the frameworks on five
variables from 1-5, 5 being high:

1.    Conciseness – How little it takes to get something done in the

2.    Familiarity – Once you get past the initial learning phase, how
easy is it to fall into the pattern of using the framework. How easy is it to
think in the framework?

3.    Flexibility – How easy it is to work with exceptions to normal
development patterns.

4.    Power – The tools to get the job done

5.    Programmer
– Is it fun to use the framework? Is
it rewarding, or does it punish you when you have to use it?



































Well, there you have it, folks. I’m riding into this one with
flame-proof-pants on, but I hope I’ve done a little good by giving the
reasoning behind my thinking. I welcome any critique of my reasoning, and if
there’s a better way to do something in my example code please put comments on
the code in Github and leave a note here as well. I hope
the example applications help, and I hope that you’ve all learned a little bit
about yourselves on this journey. Viva Flex.

Read more from
Tony Hillerson


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

I have moved to a different location

check out my new home Flexout


January 2009
« Dec   Feb »

Blog Stat

  • 84,019 Hop's so far!!!

follow me


Linkedin Blogger Twitter Youtube Orkut

Top Clicks

  • None

latest flickr photos

top rated

%d bloggers like this: