PureMVC vs. Cairngorm revisited

This post was written by jimrobson on April 2, 2009
Posted Under: Cairngorm, Flex, OOAD, PureMVC

It has been a year since I wrote my first PureMVC vs. Cairngorm post, and in that time I have had the opportunity to build more applications in both frameworks for some pretty diverse organizations. Studying the official Adobe training materials for Cairngorm has also brought some points that I had not previously considered. Perhaps most importantly, I have benefited from conversations with coders on several different development teams regarding the strengths and weaknesses of each framework. All of this experience and interaction has brought additional insight and some modification of the original opinions. That being the case, it seems to be time to post a revised comparison.

First, let me reiterate that I still like both Cairngorm and PureMVC, and that the two frameworks share a number of strengths. Once your development team has conquered the learning curve, either framework will provide the following benefits:

  • Help build complex applications faster
  • Support team development
  • Support code reuse
  • Support maintainability and extensibility

Either framework will help you build modular, loosely-coupled applications using consistent methodologies that are founded on the well-known MVC pattern. However, there are also some significant differences in the frameworks.

One key difference is that PureMVC is not tied to Flex or even ActionScript. The advantage of this that PureMVC can be used for other languages, and in fact has been ported to eleven different languages to date. The disadvantage of this is that PureMVC does not leverage native Flex features; for example, rather than using Flex binding or the native Flex event delegation model, PureMVC uses its own publish/subscribe notification system.

On the other hand, Cairngorm relies too much on Flex binding, and does not provide another way of notifying the view when a relevant event has occurred in the controller or when the model has been updated. For this reason, many experienced Cairngorm developers dispatch Cairngorm events from Commands and listen for these events in the view components - something which Adobe’s training material explicitly discourages.

Another issue with Cairngorm is that it encourages the proliferation of small classes containing boilerplate code (i.e. events and commands). While developers have found various ways around this, most of these workarounds are - again - expressly discouraged by the Cairngorm documentation and training materials.

It might be argued that the framework can’t be blamed for the fact that people misuse it. On the other hand, it could also be argued that if even experienced, senior-level developers find it too onerous to manage without making some illicit modifications, then perhaps the framework has some room for improvement.

There is one issue that I had with Cairngorm when I wrote the original post which I no longer consider to be significant: the monolithic ModelLocator. It seems that my concerns about creating multiple model locators based on business meaning were unnecessary. I have learned that this can be quite successful, even in team development contexts.

Once again, I have outlined the differences in a matrix using the AdvancedDataGrid component.

[UPDATE: I have corrected/revised the content of the matrix after receiving Cliff Hall's helpful comments below. If you have already viewed the matrix, you may need to clear your browser's cache to see the changes. ]

[UPDATE 2: Please note that there are several points listed in the matrix that are not mentioned either in this post or in the comments below. So it is worth your while to take a look at the matrix!]

This post is not intended to be the last word on the subject; rather, it is just a small contribution to the ongoing discussion. In fact, as I write this post, I am in the process of building my first significant application using Universal Mind’s Cairngorm extensions, which appear to address several of the framework’s weaknesses. I will let you know my impressions when I have completed the application. Meanwhile, if this post helps someone to make an informed decision as to which framework to use (or not) then I will be really tickled.

Reader Comments

My experience with Cairngorm has been a good one, but I’ve been ripping out what I need and using it in different ways.

All those PureMVC ports make it tempting to let go of databinding. Still, a choice between the two frameworks amounts to what fits best at the time.

#1 
Written By Mike Britton on April 2nd, 2009 @ 8:29 pm

Hi Jim,

I’d like to comment on the PureMVC ‘con’ that PureMVC doesn’t explicitly leverage Flex Binding.

Why do people feel that because it doesn’t use Flex Binding internally that’s a bad thing? It doesn’t use item renderers or datagrids explicitly either, but it certainly doesn’t discourage their use.

You can certainly use Flex Binding in a PureMVC app. It’s great stuff and I wear it out in my own apps, but in the APPROPRIATE place; Inside the view component.

Since the primary goal of MVC is to separate the Model and View, it stands to reason that you don’t want the view component to know where the data comes from, so it doesn’t make any sense at all to explicitly reach across tiers to bind to it just because you can.

So with PureMVC, we pass the data into it and there we bind the dataProviders of the child components to a local property that is the VO or scalar value we fed the component. And conversely, we do not want the Model to know anything about the view components it feeds, so when the data is modified in the view, we send an event to alert whatever is listening (in PureMVC, a Mediator) that it should grab the new data if it is interested. The Mediator then gives the data to either a command or a proxy. So the boundary objects are unaware of each other but the data still flows both ways, MVC Mission Complete!

Imagine you’re building some special visualization component to sell, like a graphing component or some such. Well, if you do that, you certainly can’t expect that this REUSABLE component you’re going to distribute will know anything about WHERE its data comes from, can you? You have to set properties on it and then watch it do its magic. INSIDE that component, you’ve got to move data around and make it available to various sub-components, and that’s the place for binding. Just try to conceive a custom component that is going to know how to bind to my application’s custom ModelLocator or find the appropriate Proxy and bind to it. You can’t do it without severely limiting its reusability by tying it to a specific framework and making all sorts of requirements about where the application’s model is and how it is structured. No one in their right mind would even try.

So why would you write the custom components for your own application any differently? If you give them knowledge of the Proxy or ModelLocator or whatever special construct you’re using in your app to store the domain entities, then you’ll never be able to reuse them, and what’s more, you’re certainly not using MVC properly.

It blows my mind that people see this lack of explicit reliance on Flex Binding as a ‘con’ when it is the very thing that allows it to also work in Flash. And virtually any other object oriented programming language in existence.

So I’d ask if you’re going to mark this as a CON that you explain very specifically WHY. I’m not asking this because I feel personally offended, I’m saying it because too many people make this statement without backing it up, and then droves of people read it and accept it as gospel because they hear it so often.

Finally, I’d just like to say that Flex is AWESOME and I want to continue working with it as long as possible and see it continue to evolve. Flex is mature already, but the community isn’t. That’s because during the process of its gestation, it cost 20k to play the game. Remember how it was in Flex 1.0/1.5? Nobody ever heard of it. It was the industry’s best kept secret. Only those with deep pockets and hard problems could participate. Hell, we didn’t even have a decent IDE. It was literally YEARS I slogged through using that horrible Dreamweaver hack, waiting for them to move to Eclipse. We’ve come along way.

Now that it’s FREE, every script kiddie on the block is able to play with it. And that’s a GOOD thing. POWER TO THE PEOPLE! The Flex community grows larger every day.

But if we want Flex to hold its own against Silverlight when Micro$oft puts the hammer down and decides it’s time to dominate the industry, then our community had better mature fast. Because the MS community is a million times larger. Silverlight is just one more thing you can do with C#, and there are a lot of well-trained MS-certified people out there with their heads screwed on straight about development methodologies that will eat all our lunches if we don’t have a clue about how to write maintainable applications. And I’m NOT saying you have to use PureMVC to do that. What I’m saying is we’ve got to curb the disinformation and rumor and grow up a bit. Our professional lives and community depend upon it.

-=Cliff>

#2 
Written By Cliff Hall on April 2nd, 2009 @ 9:55 pm

@Mike,

“I’ve been ripping out what I need and using it in different ways” - You are not alone; in fact, I’d say you have lots of company. I think part of the reason for this is that many developers find Cairngorm to be too difficult to work with out-of-the-box. And this bodes ill for Cairngorm in my view. Here’s why: When a company standardizes on a development methodology or framework, the expectation is that all relevant applications will be built according to predetermined standards, so that a new developer coming in to a project will be able to hit the ground running, because everything is familiar. However, because so many of us are acting like Cairngorm Cowboys, and just using what we like where we see fit, the result is a lot of “Cairngorm” applications that are not built according to any standard. In this way, too, Cairngorm’s ubiquity becomes less of an advantage: when a job applicant says “I know Cairngorm,” one might ask, “Which Cairngorm do you know?”

 

“a choice between the two frameworks amounts to what fits best at the time” I agree, to a point. If you are looking at it from the perspective of a development shop or consultant working on a variety of projects for diverse clients, then yes, you use what works best for each client/project. That is what I do. On the other hand, the people who I find most often asking the question, “Which development framework/methodology is the best?” are people in large organizations looking at a future containing multiple Flex projects each of which will likely be touched by many developers over course of its life cycle. These people are looking for something on which their organizations can standardize, so that they can feel confident that all of their applications are built in a way that is maintainable, extensible, scalable - and recognizable to a large percentage of developers. They are looking for the best general-purpose solution for their organization. That is where the value of comparing and contrasting the frameworks comes in to play.

 

@Cliff,

I am very glad that you wrote. I can see now how someone looking at my matrix might get the impression that I am saying “PureMVC is bad because it doesn’t use binding”. That is most definitely *not* my point! I will modify the wording in the matrix’s XML to try to clarify that.

 

I don’t know whether you had a chance to read the actual post, but I think I make my point little clearer there. In any case, let me try to develop it somewhat further now.

 

Remember that Flex *is* a framework. Specifically, Flex is a framework for building Flash applications. So, as soon as we say, “I need a framework for my Flex applications,” a red flag pops up. The question naturally arises, “Why does your framework need a framework?” The implication is that Flex is somehow insufficient as a framework, and therefore needs to be controlled by another framework.

 

Now, if by “framework for Flex” we mean a set of best practices and methodologies with *perhaps* some interfaces and lightweight helper classes that work together to enable developers to build solid applications in a standard way, I think that pretty much everyone would agree that it makes sense. On the other hand, if by “framework for Flex” we mean loading on a whole bunch of functionality that Flex doesn’t have, or that Flex does differently, then this may lead to one of two undesirable conclusions: either a) Flex is insufficient on its own, or b) my “framework” is overkill.

 

The Flex framework comes out of the box with some very nice tools to support loose coupling, and these tools include the event delegation model and data binding. So when we place a framework on top of Flex that essentially sets these tools aside and imposes its own methods for communicating between application components, the question naturally arises: “Why?” I think that you have stated the answer to this question very well: “it is the very thing that allows it to also work in Flash. And virtually any other object oriented programming language in existence.” As it happens, I noted in my post that this is an advantage.

 

However, this is not a perfect world, and each advantage tends to carry with it an associated disadvantage. The PureMVC Notification model is a beautiful thing. I congratulate you for developing it. I love to work with it. However, it requires the developer to learn an entirely new and different model for communicating between components in addition to the native Flex model. And any developer who is not familiar with both the PureMVC model and the Flex model will be unable to work on a Flex PureMVC application without making a mess.

 

In this not-so-perfect world, then, we need to weigh the advantages against the disadvantages in order to make our decisions. If it is important to your organization that you build your Flex applications using a framework that can also be used with a large number of other languages, then this will tend to outweigh other considerations. However, if your organization already has standards in place for all of the other languages that you are likely to use in the foreseeable future, then this portability may not seem like much of an advantage to you.

 

I hope this clarifies my point somewhat.

 

Regarding your concerns that we in the Flex community need to build our OOP skills, I agree. That is why I wrote posts such as this:

 

http://www.robsondesign.com/blog/index.php/2008/11/30/xml-and-the-avanceddatagrid-step-two/

 

And this:

 

http://www.robsondesign.com/blog/index.php/2007/10/18/managed-associations-vs-hierarchical-values/

 

Finally, I have one more thing to say to you, young man. When you get to be my age, then you talk to me about “growing up”! ;-)

#3 
Written By jimrobson on April 3rd, 2009 @ 10:09 am

I would argue that Flex is a not a framework so much as it is a toolkit.

Compare:
http://en.wikipedia.org/wiki/Widget_toolkit
http://en.wikipedia.org/wiki/Framework_(software)

Flex gives you a big bag of tools, some of which operate together and provide you with various ways of handling communications and display of widgets, etc. But it does not dictate the final form that your program will take.

If you write Flex apps with nothing other than Flex there are myriad ways to solve the problem of retrieving data, displaying it and letting the user interact with it. There are no rules. Use data binding if you like. Or don’t. Put everything into one big MXML file (the unified file theorem), if you like. Or break it into 500 classes and figure out your own roles, responsibilities and collaborations. It’s up to you.

A framework on the other hand dictates to some degree what the final shape of the program will be. All PureMVC applications essentially look alike. There is an accepted startup proceedure, and the actors all have well defined roles.

Of course this is a debate that could go on and on, but for those new to Flex and frameworks like PureMVC and Cairngorm, it’s reasonable to make the distinction.

Yes, Cairngorm and PureMVC DO add something Flex is missing: a structure for your program, and a methodology for using the tools in the Flex toolkit in a reliable way that makes the code you write more maintainable and can yield some modicum of reusability in the components at the boundaries of your application.

Old timer, eh? hah! Why, when I started out, we didn’t even have 1’s, we had to write all our programs with zeros! :)

-=Cliff>

#4 
Written By Cliff Hall on April 4th, 2009 @ 6:02 pm

@Cliff,

I wholeheartedly agree with your description of the value that PureMVC and Cairngorm add to Flex (very well stated, by the way).

As to what you say about 1’s and 0’s - well, I have to admit you’ve got me beat. I can’t top that!

#5 
Written By jimrobson on April 5th, 2009 @ 11:23 pm

You have listed the availability of business delegates as a pro for Cairngorm, however there’s no reason you can’t use delegates with PureMVC that I can see.

#6 
Written By Phil Douglas on May 29th, 2009 @ 2:29 am

@Phil,
You may be right, but I was trying to compare the two frameworks as they are presented by their creators, so I did not intend to include non-standard variations. I suppose you *could* use Mediators with Cairngorm, but such would not be a part of the Cairngorm framework per se.

#7 
Written By jimrobson on June 2nd, 2009 @ 9:30 am

I have to say, this is the best post and comment banter I’ve come across in quite a long time. All I can say about the age thing is, “Thank You” to both of you for paving the way for me to do what I am proudly doing today. :-)

@Cliff,

When it comes to more developers and engineers joining the Flex community, it excites me tremendously because the larger the community is, the better the product will be over time. I mean, look at Java in 1995 and look at Java today. Can anybody else see a pattern or is it just me?

Finally, I have a general question that I wish I had an answer to yesterday because it has always been in the back of my mind, but never came out until now. :-) My company forked out the 20k and I was one of the lucky few to have had the luxury of working in Flex when it first hit the market. Only recently have I begun to realize just how fortunate I actually am.

My question is, how many (Senior) Flex developers in existence today have been using it since its inception? Easy enough, right? ;-)

#8 
Written By Matthew Zimmer on February 6th, 2010 @ 6:08 pm

HI,

Regarding the 1st point in your Cons :
” Cairngorm does not provide a way to notify the view of relevant events in the controller (or updates to the model) apart from binding. Binding alone is not sufficient for all situations.”

I have solved this problem using the “call back function with the help of event”. I have add one call back function in the event and at the time of dispatch the event from view, i have set one function of view as call back function and call that function from controller to pass the control from controller to view.

So, I think don’t need to dispatch any event from controller to go to the view.

Regards,
Dipankar Paul
Flex Developer at RandemIT Pvt. Ltd.,
India

#9 
Written By Dipankar Paul on June 16th, 2011 @ 12:26 am