Tuesday, October 30, 2007

Cairngorm vs PureMVC : a quick comparison

After watching Ali Mills and Luke Bayes presentation comparing the available Flex Frameworks I decided it was time to have a much closer look at PureMVC. After spending some time getting familiar with PureMVC it is hard to argue with their conclusion that PureMVC does a better job of solving many of the potential problems of using an MVC pattern. PureMVC is less dependant on Singletons, individual components are more reusable because they have fewer dependancies and there is less repeatition in setting up new functions within the framework. Despite all of these benefits I'm not convinced that this makes PureMVC a clear winner.

Towards the end of the Framework comparison presentation it is pointed out that Cairngorm is the framework that all Flex developers need to know. Well it would be nice if there were a few more developers in Melbourne who know Flex. Let alone developers with an understanding of Flex Frameworks. So the question I asked myself is if I had to train someone new next week who was unfamiliar with any Flex Frameworks which Framework would I want to teach them. The following table lists the concepts you need to understand for Cairngorm development compared to PureMVC. What is immediately evident is that there is a lot more to learn to get up to speed with PureMVC. To achieve a cleaner/purer framework PureMVC has added more complexity and this is a problem when you need to train people to use a Framework. When we started using Cairngorm it didn't take long to explain the basics of the Framework. But I think it would take a lot more explanation to get started on PureMVC despite the similarities in the two frameworks.



Anonymous said...

I totally agree with your conclusion.

Not only is PureMVC harder to learn, but the new user is at a quadruple disadvantage -- there are no tutorials (not even one) that I could find on using it with Flash CS3 and even PureMVC's own 'Getting Started' forum has nothing on getting started.... that is, if like me you believe that the one Flex 'tutorial' there passes as a tutorial, which it doesn't.

Released months ago and no one, anywhere, seems to have considered it worthwhile to write a tutorial on this framework! Hmmm....

Meanwhile, I'm sticking with Cairngorm which has excellent descriptions and well explained tutorials. I was up and running in a short while compared to my experience with PureMVC eg. I don't yet have any experience with PureMVC inspite of a couple of days work!

geekglue said...

Thanks for your comments. To be fair there is a PureMVC Courseware beta program (http://puremvc.org/component/option,com_wrapper/Itemid,139/) . If you can get on the beta then you would probably find all the getting started stuff you would need. But the absence of some publicly available materials of a similar quality is a genuine obstacle to newbies.

Newbie said...

I'm not sure I agree with your comparison here... I am equally ignorant in Cairngorm as PureMVC... from a brand new user perspective, they are the same difficulty.

You missed some learning points in Cairngorm: CairngormEvents = notifications...

I found the two frameworks line up pretty closely, PureMVC just puts a bundle on the singletons into one item called a facade.

Basically, I've found both to be pain to learn both with terrible examples. The courseware hopefully will help (I'm in the beta). For clear, easy getting started for Cairngorm see davidtucker.net and his getting started series - Adobe should hire him.

geekglue said...

Thanks for the comment Newbie. Fair point about CairngormEvent. I've added to my list as well as Delegate and Service. I found both difficult to find a starting point. But once I had my bearings I found Cairngorm easier to maintain a clear understanding of how the parts relate to the whole. It may relate to PureMVC's terminology. It doesn't seem obvious to me what the Mediators and Proxies relate to. So I find I have to keep reminding myself.

Anonymous said...

here's a crazy mixed up idea. these flash/flex frameworks are total shit. Anytime you start off with a bunch of classes generically named after patterns you are fucked. This is not how you program. learn OOD. The class is a thing, not a pattern.

Anonymous said...

Geekglue said:
> It doesn't seem obvious to me what the Mediators
> and Proxies relate to. So I find I have to keep
> reminding myself.

This was exactly my problem. When I read the documentation, I was fine... until mediators and proxies. The explanations about mediators and proxies fit into PureMVC were either too quick or too incomprehensible or too vague, or they made huge assumptions of the reader.

I became totally lost - never normally a problem on the internet because you just go somewhere else and fill in the gaps, but with PureMVC there is nowhere else to go other than the PureMVC docs.

geekglue said...

I think it's going too far to write off frameworks altogether. A framework is about having a consistent way to structure projects. There are a lot of benefits that come from that consistency even when the framework has imperfections. I take it as a sign of the growing maturity of the Flash platform that we can now argue the comparative merits of a range of frameworks. I'm also not sure I agree that mapping class names to pattern elements automatically invalidates a framework. But I take your point.

Anonymous said...

another problem is that MVC is not that complicated. Its really disturbing to see directories named "model" and "view" and "controller" as if the MVC pattern was a way to name your packages. ITS NOT. The flash development community is probably the most immature and lacking in terms of good software design.

If you want to use MVC use it CONCEPTUALLY. Certain classes will be views and others will be controllers. You dont need to make little folders (misusing packages -- happens everywhere in flash/flex development) with the views in one place and the controllers in another. You dont even need to name a class SomethingView if the comments indicate it is a view. Since the view may only be part of its general behavior. This is one of the most embarrassing things about these frameworks -- MVC is not rocket science. Its just a concept with some basic implementation. Its like people saying "I used a singleton" STFU.

Simon Bailey said...

quote: "...there are no tutorials (not even one) that I could find on using it with Flash CS3"

Lets get that sorted the :)


Peter said...

I would never hire someone who doesn't know (most of) these basic design patterns ;)
I would tell him about the "Head First Design Patterns" book and ask him to come back after studying it.

geekglue said...

Hi Peter,

half your luck is all I have to say. When we were looking for a developer late last year/early this year we weren't able to find someone with Flex experience let alone Flex Design Pattern knowledge. Based on some discussions I've been having this week I'm not sure the situation is greatly improved in our locale.

Anonymous said...

This post is complete rubbish, It is so ignorant i'm not going to waste my time pointing out the IDIOTIC comments you have made.


Mr D said...

Thanks for the iput guys. I'm currently in South Africa, new in Flex and trying to research which framework to use for my project. I got started in Cairngorm fairly quickly. PureMVC? I understand the concept but documentation is pretty much scarce. Which framework are you guys using in your projects?

geekglue said...

Hi Mr D thanks for the comment. For our part we continue to use Cairngorm and while we watch the emerging frameworks space with interest we plan to continue using Cairngorm in the near furture.

geekglue said...

To Plank,

glad you felt the need to make the comment. But it is hardly of value to anyone to make such an excessive comment without backing it up in some way. The purpose of comments is to engage in the conversation by offering alternative perspectives, new information or a sense of shared purpose. Pointless abuse represents one of the worst aspects of forum culture and fortunately blogs are mostly free from this behaviour. To flame without discussion usually suggests personal issues or an hidden agenda. Good luck with that ;o}

Canyoneering said...

Cairngorm's "solution" involves storing all of your state in a big global-variable store. Sure, they call it a "model locator" - but it's just a glorified global variable store.

All of your stuff becomes tightly coupled to the model locator, and all of your code becomes very non-portable.

Sure, it's EASY to do up front - but it's not good OOP to do.

Also, Cairngorm is not module-friendly.

I don't think PureMVC is perfect, but I can tell just by looking at the "architecture" behind cairngorm that it sucks.

geekglue said...

Thanks for your comment Canyoneering. My understanding of PureMVC is that it still uses a "global variable store" but all interactions go through one global gateway (the Facade). Making it an improvement on Cairngorm.

With regards Cairngorm and Modules we use Cairngorm and Modules without any problems. I remember a lot of posts regarding problems with Cairngorm when Modules were initially released. But that subsequent releases of Cairngorm have dealt with this issue.

"EASY" vs "OOP". We're all looking for a Framework offering easy and OOP. But if I have to choose one over the other my hand is up for easy everytime. That is surely sacrilegious to the purists. But I make no apology for choosing practical over purist.

I hear and understand your point about everything being tightly coupled to the model. This isn't entirely true. If we can imagine that the model is like the foundations of a house. If the foundation is solid then you can attach other things to it with confidence. When you add a fridge to the house it takes advantage of the foundation but it's not tied to that foundation. It can be used in other houses. Therefore having a global model doesn't stop us from building portable, re-usable elements when that is appropriate.

Mark Ellul said...

I used to think Cairngorm was better in terms of documentation.

Though I revisted PureMVC in the last month and the site has fleshed out alot...

Also its easy to find examples and source now...

PS. You have to love how they ported PureMVC to different frameworks..

Which is good considering that Silverlight may catch up with Flex some day!

Tech Per said...

I have just done some learning on Cairngorm and PureMVC, and would like to add my comment here.

True, that PureMVC has the worst documentation. But Cairngorm docs are not that great either.

Keeping at it, digging in PureMVC, I found their demo on multicore (with the "multitons" :-)). I downloaded the source, took a look at it, and knew PureMVC by half a days work. So, finding the best "documentation" (the source of the example) was what took the time.

Actually, when looking at the classes in the apidocs, both of the frameworks are very easy to grasp. There are very few classes and concepts to understand.

I hear again and again, that all flex developers need to know Cairngorm. I do not agree. If you know PureMVC, you can grasp Cairngorm in a second, and use that instead. They are very alike.

Instead, one should try and look for developers who know how to learn, instead of developers who know exactly the frameworks the project is using.

geekglue said...

Tech Per tHanks for your thoughtful comments. Your right in saying it's best to look for people who know how to learn rather than people who know the framework you are using.

Anonymous said...

pureMVC IMHO is very far from being f flex-fiendly, its a first of all general implementation, has extremely large number of unnecessary implementation classes,
and it is not using any of flex frameworks build in handy classes,
cairngorm so far is way above pureMVC .

Per Olesen said...


Could you share some concrete examples?

What are the "...extremely large number of unnecessary implementation classes.." in PureMVC and which "...flex frameworks build in handy classes" is it missing to use?

Royston said...

I've done a lot of MVC stuff in the past with a large variety of frameworks (most of which confused the controller concept with the view concept in various ways) and so have been interested to see Cairngorm + PureMVC. They're both pretty abstract and sparsely documented, but the new 'best practices' document from PureMVC does a good job of explaining the concepts better than any of the other PureMVC + Cairngorm documents I've yet (May 2008) to come across, and actually bothers to give concrete examples of what the various objects should and should not do in their interactions with each other. Pretty useful stuff.

Not sure which framework I'll go with yet: PureMVC MultiCore looks much cleaner, but Cairngorm is better known. Hmm...

Tyler said...

I agree with Royston, when I first discovered PureMVC, it was hard with the Flash IDE to understand what was going on let alone having some familiarity with most of the patterns used, but after using Flex and reading the latest documentation I have started using the framework with most of my projects, big or small. It is weird to have the classes named after the patterns themselves...but how can u forget what they do? I would recommend to anyone that plans on working with other developers to learn at least one of these frameworks.

lauren said...

I'll agree that when our company was choosing between Cairngorm and PureMVC, PureMVC was definitely harder to pick up and use straight away.
We ended up sitting for about an hour and having no problems understanding a few Cairngorm examples, but were a little perplexed when it came to the few hours we spent making sense of PureMVC.
In the end, we decided to go with PureMVC because it gave us more flexibility in how to set up our app and was easier to get around using the facade. Despite the learning curve (which tended to be fairly quick after an in-house demo or two), we're very happy with PureMVC!

geekglue said...

Thanks to Royston,Tyler and Lauren for your comments pro-PureMVC. I think after reading your comments that I need to take another really close look at PureMVC. The PureMVC documentation has definitely improved since I last looked and it's true that a slightly more complex system that yields long term benefits is definitely worth the effort.

Daniel said...

I have to give another thumbs up to the PureMVC best practices document, but a thumbs down to the amount of official Flash CS3 examples, which seem to be lacking a bit. I'd like to see a couple more examples added.

Jonathan Rowny said...

A few people have posted that the facade in PureMVC is akin to the locator (a giant global variable) in Cairngorm. It's not! At least it shouldn't be! If you're storing a bunch of global vars in there, then you're not understanding the facade. The facade is meant to give you easier access to different parts of your application (i.e. a proxy).

I've also adopted PureMVC over cairngorm. To those who think no framework is needed, you're not working in a team.

ccapndave said...

Hey all,

PureMVC is definitely lacking tutorials, so I've done my bit to help out by writing one :)

Check it out at http://www.actionscriptdeveloper.co.uk/puremvc-tutorial-flex-puremvc-jabber-and-xiff-3-introduction/



Flexian_NGL said...

I am newebie to flex, I want to learn PureMVC, from where i could get the docs and others for that

geekglue said...

Any available docs for PureMVC are available from their site (link at top of this post). As many of the posts above attest the documentation for PureMVC is quite good.

Sputnikenmeister said...

I used Ariaware when as2 was the only thing under the sun, and it's a helpful tool to add developers in the middle of a project; it gives a common language to explain the inner workings of an app. That's one of the advantages of patterns. That said, patters are both a vice and a virtue. Coding away from patterns will make your code more straight fwd and possibly more efficient at the micro level, but unreadable and unmanageable at the macro level. So I agree that patterns must be taken at the conceptually. Both frameworks introduce a fair level of dependencies, which makes them fairly modular-averse, but MVC is a proven institution with many better variations in other modern languages (see java, c# -a port would be easy); Documentation wise, a MVC tutorial is also conceptually valid for as3, and there's a myriad of them to show how both Cairngorm and PureMVC an be improved; a java tutorial can perfectly do the job. MVC has been there since mx.core.UIComponent, although at the widget level.
But here's my grain of salt for the Cairngorm/PureMVC discussion: both are similar, but choosing a framework can tie you down in the long run, so longevity can be an issue. Adobe has its weight on Cairngorm, but how long is PureMVC going to be around and maintained? That said, there's room for a clearly superior MVC set of interfaces, I can see it pushing Adobe's away...

Jason said...

I would love to revisit this post after a year has gone by and see what people are saying about the comparison between the two frameworks again. Both frameworks have had great leaps in support with both documentation and examples.

What bothers me are the comments that state that frameworks to not imply OOP. Frankly I really don't care what people do or do not think the frameworks implement as the bottom line is what framework provides ease of maintenance for the client that paid the money to have the application built in the first place. As well as the time line it takes to develop the application so that the client can start making a profit.

Bottom line for all the purist out there is that we develop applications for our employers so that they can make money. If you build something that is unsupportable and/or maintainable then its shit no matter how pure the development is. Its all about time to market and stability, not pure OOP.

Just my 2 cents. ;-)

guyinthechair said...

A disingenuous comparison of the two frameworks.

First, saying "This one has more classes! It must be more complex!!" is akin to saying that since someone has a larger head than I do, they must be smarter than me.

Secondly, you list the Model, View, and Controller singletons as classes you have to know and/or deal with. They aren't. As someone who has developed countless PMVC apps, I've never had to rewrite or subclass or directly access any of these classes. Observer and Notification are two classes you can do without knowing very well... the only thing you care about Notification is that there are getName(), getBody(), and getType() functions. And that's really implemented by INotification.

So If you're talking about classes you will regularly write and interact with, those would be your custom ApplicationFacade, SimpleCommand (possibly MacroCommand instances as well), Proxy, and Mediator. Funny how that list is shorter than your Cairngorm list too.

geekglue said...

Firstly, thanks for the comment guyinthechair. I think you are being a bit unfair by describing my comparison as disingenuous. I would describe my comparison as highly simplistic but I was quite genuine in my observation that for someone coming to the two frameworks with little experience there are clearly more bits to PureMVC. True once you start using the framework you won't need to directly interact with all the bits. It is still best to understand the relationship between the bits before you start using either framework.

What I find really interesting is how heated some of the responses to this post are. As Jason pointed out it seems to divide readers between the purists and the realists. My view now is that neither framework is ideal and that the benefits of one over the other ,in most projects, is exaggerated. The reason new frameworks continue to emerge is that many are unhappy with the existing options.

guyinthechair said...


True, there are more bits, but I disagree that you have to have an understanding of all of them before you can utilize the framework. Adobe certainly doesn't think you have to understand ChangeWatchers to use data binding all over the place (a much more destructive practice, IMO).

And as to purists vs. realists, why can't you be both? PureMVC is not your application. PureMVC is a base architecture, a foundation for your application. Why should you have to recalculate the correct recipe for cement every time you want to build a new house? Pour it in and go! If you've ever met, discussed with, or heard a presentation by Cliff Hall, you'll quickly realize he is a realist. He did write Flex applications without a pattern-based framework. And for a long time he also worked for a Cairngorm-only dev house. It was only when he realized he was reusing his additions to Cairngorm that he broke it off into PMVC.

Cliff constantly says you should use the shortest/easiest path to your solution. He just set (and I agree with him mostly) some ground rules on how that should happen. PMVC isolates the model so it isn't ever tied directly to your view (portable models are nice things). But if you want to call directly into the model from your view (thus, tying your view to your model), it's your prerogative. He encourages black-boxing your view components (de-coupling them from your app) for portability, something that helps even with no framework at all.

If you haven’t already seen it, check out the Silicon Valley FUG’s presentation on frameworks.

Sorry if my post sounded heated, I should have previewed what I wrote before I published it. However, I noticed you never directly addressed my brain-size analogy ;)

And yes, frameworks tend to group people. Frameworks are the new religions! (what does that mean if I'm non religious?)

geekglue said...


thanks again for the comment.

Why should you have to recalculate the correct recipe for cement every time you want to build a new house?

We are in agreement here that's why we are talking about frameworks. Really we are just quibbling about the brand of cement we prefer. Portability is obviously a great thing. But I've never had any trouble making the views I expect to re-use portable. At the same time I find I need some very custom window frames that I can't imagine using elsewhere.

Once again I'm ignoring your brain analogy.

Dan Lavender said...

There's some talk on here about not using frameworks at all and just using MVC principles. Yet nobody has really mentioned team development or Extreme Programming here.

Personally, these frameworks are essential if you're doing any modular, rapid agile development in a large team. Sure you can use MVC principles to start off with, but after a while, you'll find yourself rebuilding what Cairngorm or PureMVC have straight out of the box.

Personally I go with PureMVC as, unlike Cairngorm, it is not Flex/Flash specific and therefore knowledge gained with the AS3 version is a valuable asset if you need to do something similar in C# or Java, for example.

ClarkKent said...

First of all, I question the need to apply the MVC pattern to Flex apps.
MVC is useful in JSP Web apps because it helps to keep Java code out of the JSP file.
Flex does not have that problem.
JSP apps can also benefit from having a central controller to help keep users from accessing pages when they are not logged in.
Flex also does not have this problem.

I have not seen PMVC, but I have taken a look at Cairngorm.
Here are my view of the weaknesses of Cairngorm:

1. Too much code to write: Forces you to write a separate command class to handle each event.
Having both command classes and delegate classes may be redundant.

2. In most cases events pertain to one UI component and affect only that UI component.
But the command pattern used for events disassociates the event handling from the component.
This makes the code harder to understand. This much separation reduces cohesion of the code, which makes the code less object oriented.
OO says that things that pertain to an object and only that object should be combined with that object.

3. The ModelLocator idea pushes the coder to the idea of using global variables.
Sometimes sharing data among components is useful.
But most often a data variable is required by only component and should not be made global.

4. Cairngorm seems to assume that you will do data binding using the {} on global variables of the ModelLocator.
It assumes that you will not want to use ActionScript to assign the data providers.
Why do I say this? Because the command classes are disassociated from the internals of any components.
So, for example, to set the dataProvider of a dataGrid internal to a component, the command class has to
a. Find the component
b. Mess with the internals of the component by fiddling with the dataGrid directly, which requires that the dataGrid
be made public or that a public method be created in the component for the purposes of affecting the dataGrid.
SO the result is that if you want to set a dataProvider via ActionScript, a reference to the component instance has to be
found (via the event perhaps) and the guts of the component have to be exposed

The principles of Cairngorm that are reasonable to me are
1. Services that need to be shared should be isolated from components
2. Some data may need to be shared.

Dan Lavender said...

Another thing to bear in mind for both Cairgorm and PureMVC is how much of it to use and when.

There's no right or wrong answer for that and it's application and developer specific.

I'm currently re-architecting an existing app into PureMVC Mutlicore as features will need to be added or removed quickly, without affecting the core application.

The point is: I could spend a long time creating a new "perfect" PureMVC application with everything a command/notification/mediator/proxy etc. Or I could use PureMVC notifications to control the hooks between various blocks of functionality within the existing application, using proxies for shared data resources.

spalios said...

doesn't help at all !!! i think the best way is to learn one framework and then another... it looks like both of them are pretty equal...

Frank said...

You should abandon both of these overcomplicated frameworks and use JavaFX instead.

geekglue said...

Hi Frank. First let me say LOL! If we did find these frameworks over-complicated we'd probably consider using Flex in a more KISS way. I really hope that JavaFX grows into something useful because having real options is vital for the future of RIA's. Perhaps I'm missing something but I've yet to see any evidence that JavaFX is going to become a real alternative. But perhaps you already know that and are just looking for a cheap laugh.

Anonymous said...

Great thread going here. My quick contribution: I simply don't find Cairngorm intuitive whereas I was able to start working with PureMVC in about an hour and now use it for all of my projects. Sure, the classes are named after design patterns but, eh. And you don't have to create model, view and controller packages if you don't want to (I do; seems perfectly fine to me).

I'd like to spend a bit more time with Cairngorm to try and understand how all the pieces fit together, but it really just doesn't click for me the way that PureMVC does.

Here's a useful exercise for those trying to decide which framework (er, microarchitecture?) would be a better fit for them; compare these two diagrams:



Whichever diagram makes more sense to you probably represents the framework (excuse me, microarchitecture) you'd be more comfortable using.

Nick Polet said...

The comments about PureMVC's lack of documentation dont hold anymore, there are quite a few great tutorials out there plus Cliff Hall (PureMVC's creator) has put a load of great presentations on puremvc.tv that are so helpful.

I am thinking of learning Cairngorm soon, but I`m quite happy with puremvc. I dont really see the need to worry about which one to use. I have had a great experience with puremvc which has let me create clean projects with modules that I am using in multiple projects. I havent had any problems at all with it.

I quite fancy learning cairngorm, purely for the fact that its supposed to go well with flex, plus I know quite a few people developing with it.

guddu said...

Can you please show some example along with these cmparison