In the last months there have been several blog posts about the evil that is Cairngorm. People are complaining about the framework on mailing lists and on forums and when talking to other developers, a lot of them seem to dislike Cairngorm, mostly in favor of other frameworks. Some projects I consulted on (often too late) were actually being refactored/rewritten to move away from Cairngorm.
I noticed however that the opinions often lacked strong arguments, if any at all, that were convincable enough for me to truly dig into other frameworks. In some cases, I felt that the choice of a framework was based on a hype and prejudgement towards other frameworks. In particular PureMVC is getting a lot of attention and I can’t remember how many developers I have heard saying that they were using PureMVC just because “Cairngorm sucks”.
Don’t get me wrong. I certainly don’t want to start a religious war between the Cairngorm, PureMVC and other framework followers. I’m all for a little “competition” because I believe it drives innovation. We’re even offering extensions to both frameworks in Prana and since people are using them, there certainly will be good reasons that justify the use of one of the two frameworks.
However, I was wondering what your opinion was on Cairngorm. What in particular is it that you don’t like about Cairngorm and if you could change things, what would they be? On the other hand, what things do you absolutely like about the framework?
Add to Bloglines - Digg This! - del.icio.us - Stumble It! - Twit This! - Technorati links - Share on Facebook - Feedburner
Christophe Herreman is a software developer living in Belgium. He's working on high-end Flex and AIR solutions at 
August 5th, 2008 at 10:17 pm
I’ve primarily used Cairngorm, but just learned PureMVC last month and have been using it in some projects. The two main things I don’t like about Cairngorm are forcing everything to be updated in the view via binding from the model, as well as having no hook back into the view. I very much enjoy the mediator approach in PureMVC for this reason.
August 5th, 2008 at 10:37 pm
I agree that there is a lot of FUD around using different frameworks. I personally have a difficult time evaluating them on projects due to the risk involved — what happens if the framework doesn’t work for your client/project/team? Start over? Ugh.
At the end of the day, everyone has to make their own decisions about which religion/framework they want to practice/use.
My hope for the future of Cairngorm is that 1) we get some official support for AIR/SQLite and 2) we will get some more transparency into the future of the framework. Everyone else is banging their drum, but the fine folks at Adobe Consulting have been far too busy to respond all that much.
@Greg J: Take a look at UM’s Extensions: http://code.google.com/p/flexcairngorm/
I have not had the opportunity to use them yet, but others have said that they address the problem you cite. Unfortunately, the Flex Store app using these extensions has not been completed yet (hint, hint, UM!
Leif
Atlanta
August 5th, 2008 at 11:03 pm
I’ve built large-scale apps sans-framework, with Cairngorm, and with PureMVC. I definitely prefer PureMVC and will probably continue to use it for future applications. While it is in no way perfect, I will probably use it to contrast the problems faced in Cairngorm in this post. Lastly, I’m not a Cairngorm expert, so if anyone has any information that differs, please correct me!
I will try to stay away from the Singleton==Global Variable argument. I’m not here to dispute dogma.
Cairngorm has some great features, but I think there are a few ‘sore spots’ in terms of real-world usage that keep me from wanting to use it exclusively.
1) Global ModelLocator
Cairngorm relies on the extremely useful Binding feature in Flex. The ModelLocator can become unwieldy if it not only maintains the state of the data, but also maintains state information for the view. In the examples you frequently see a workflowState variable in each model. This is frequently sufficient. But, when there is more state to be maintained, either the Model becomes muddled, or on to my next point, the View becomes overly complicated.
2) View Logic and Dependencies
In building custom components, I find that defining the exact data dependencies for that component and then using property injection and standard event dispatching allows for decoupled components. In Cairngorm, your views are dependent on both your current configuration of your ModelLocator, and the CairngormEventDispatcher.
I like the idea of a ViewController that handles one or multiple views and allows them to remain decoupled from the framework and a specific ModelLocator. I think that writing Views to stand alone from the rest of the application is very important in building a maintainable (and testable) application. Cairngorm’s ViewLocator/ViewHelper has been deprecated… I think that was a move in the wrong direction.
I also find that, because Commands only update the Model, as I mentioned above, you either rely HEAVILY on state variables in the Model, or, in the View, your code becomes very complex in order to handle the different possible states.
A common example in the Flex world is an employee list and employee editor application; the standard configuration is to have a currentEmployee in the Model that is a EmployeeVO of some sort and the EmployeeEditView binds to that currentEmployee. This is very sweet. When you are done you just dispatch an event and a Command updates the backend to reflect your changes. However, if you wanted to open TWO employees at once, suddenly your currentEmployee isn’t sufficient and you must employ trickery to handle this. The folks at UniversalMind have introduced a set of extensions to Cairngorm that help alleviate this problem. They’ve introduced a view callback that allow Commands to directly inform a View of the result of an Event/Command. This way, I could request and get the employee details and not have to maintain an array of openEmployees in the Model. Which employees are being viewed should have no bearing on the Model unless it’s relevant.
That’s about all I can think of for now. While these are my complaints with Cairngorm. None of these issues are dealbreakers–they just require the developers to be aware and take care to keep the view relatively decoupled and keep the model clear of excessive state saving. I think that the UM Extensions are a great addition to the Framework. Just because it’s a framework, no-one ever said you had to use it as-is. I would gladly use it on a project. I just prefer PureMVC, personally.
August 5th, 2008 at 11:42 pm
I’ve been using Cairngorm across two large enterprise applications for over a year now, and I really don’t mind it at all. A lot of the arguments I hear about the boilerplate code and having to create too many files, etc, seem to be made from people who don’t really need a full MVC framework and want to take shortcuts. I’ve done that in many smaller projects and it definitely leads to rapid development. I also think sometimes people aren’t willing to modify Cairngorm beyond what it is, which is extremely basic. The UM Cairngorm extension provide lots of useful enhancements like callbacks, but came around too late in the game for me. We have our own base classes that extend the Cairngorm classes to provide functionality we need such as callbacks and tie-ins to our model locator base classes. I also see a lot of people using a monolithic ModelLocator for some reason, whereas on large projects I create many ModelLocators to have separate data stores for different types of objects. To me Cairngorm does exactly what it’s supposed to, provide MVC separation. If a bug is logged against one of these enterprise flex apps, I can almost always pinpoint the exact file I think the bug is in or I at least have a really good starting place just because of the logical separation of files.
We use Spring on the server side and I really need to look into Prana. I can probably relieve some of the few boiler-plate sections we have, such as passing arguments to the base class constructor for our Commandss telling it what model will be affected and such. That could probably be set up in XML and injected at runtime.
August 6th, 2008 at 12:03 am
Cairngorm is a good “starter framework”. It’s good to get developers thinking about MVC using data binding. But I don’t agree that it’s an enterprise framework; there are too many real-world scenarios that Cairngorm doesn’t show how to address, especially when it comes to code reuse.
A few technical notes: In Cairngorm, every Command object has direct references to the application’s ModelLocator singleton. This means that you can’t possibly reuse the Command classes in other applications. The view binds directly to the model, so you can’t reuse your Cairngorm views (although you can still build view components and reuse those). The FrontController serves no programmatic purpose; You are only allowed to program the FrontController to do one thing only and that is to take events and map them to commands with the same name. Time spent maintaining the FrontController is time that we are not spending writing an application.
But I also disagree with the idea that you have to chose one framework and stick with it. There are many smooth transitions available to migrate from Cairngorm to other frameworks. Mate, for example follows the same datapath, but it does it in a way that gives more programmatic control using the EventMap instead of a FrontController. It is easy to migrate one small class at a time without having to do the whole framework move at once.
And in all honesty, probably the biggest problem I have with Caingorm has nothing to do with the technology, but rather with the lack of documentation. There are not enough real-world examples in the official Cairngorm docs, and there’s no way to know which unofficial docs to trust. Mate, on the other hand has 8 different application examples, selected to fully illustrate a wide variety of real-world scenarios that the framework addresses.
How can anybody think that the official Cairngorm site explains what you need to know use Cairngorm for an enterprise application? ASDocs does not tell you anything about how to use Cairngorm. Beyond that, three partially documented examples is all they have. This site appears to have just graduated from a “coming soon” page:
http://www.cairngormdocs.org/
I think that Cairngorm can probably do a lot more than I’m aware of. I’m sure it has a way to deal with cross-cutting concerns such as our “ChatManager” that we had to write outside of the Cairngorm framework (utterly breaking Cairngorm’s design pattern). But we just couldn’t find one single example about how to do anything close to what we were trying to do in Cairngorm.
One last thing: Cairngorm has not grown for over a year. (The last blog post on their official site was in July 2007, and the last dot-release was even longer ago than that.) In software, anything that doesn’t grow dies. I don’t believe that Cairngorm is so complete and thorough that it doesn’t need any new versions. It’s being leapfrogged by frameworks that are growing actively, such as Mate.
Mate basically supersedes Cairngorm. It does everything that Cairngorm does, and it does everything that we all wish Cairngorm would do. Especially when it comes to enabling cross-cutting concerns, and de-coupling the model from the controller and the model from the view.
August 6th, 2008 at 12:06 am
I don’t want to steal other’s thunder, so over the next day or so, keep watching blogs.adobe.com for an update that will make you all smile.
There’s little value in ” is evil” or ” sucks” discussions though, IMHO….that’s not going to engage me or any of the Adobe Consulting team. No-one wins in these discussions, and the community just tears itself apart.
Watch Alistair and I’s blogs in the next day or so.
August 6th, 2008 at 12:08 am
Leif — “everyone is banging their drum but the fine folks at Adobe Consulting have been too busy to respond”. I just checked my inbox and outbox, and I’ve replied to all of your emails…let me know if there’s anything outstanding
August 6th, 2008 at 12:19 am
@Steven That was NOT what I was suggesting, Steven! You’ve been awesome! That was a nod of understanding that, while you guys are responsible for Cairngorm, you guys also have a lot on your plate. Kind of like my hint to UM to get the Flex Store example done sometime soon (please) — the reason it isn’t done is that UM, like AC, has paying clients that must be serviced!
I look forward to your smile inducing update, as you know how much I love Cairngorm.
August 6th, 2008 at 2:42 am
As much as I love Cairngorm for its simplicity, there are of course, a few pitfalls to it compared to PureMVC.
The most obvious issue will be updating the view from command by using only state variables. Although that can be a double edged sword as there are times when it works very well and times when not.
However, on the overall, I still prefer Cairngorm for now over PureMVC, for simplicity sake.
August 6th, 2008 at 8:28 am
Thanks all for commenting. I have briefly looked at the UM extensions and will certainly investigate them further.
@Steven: I’m very curious about what you have to announce. Don’t keep us waiting too long
My intention was not to start an “is evil” or “sucks” discussion, but I was merely using these terms to show how easily some developers ignore Cairngorm without really being able to argument why. In some cases I found that they actually know very little about the framework and that is what brought me to this post.
In general I agree with most of the issues that were mentioned here in the comments since I have dealt with them too and wrote a set of extensions myself to handle them. That’s why I find it strange that since so many people are having the same issues (and I think AC has these issues as well), there is no real answer coming from AC directly that offers a solution to these problems.
I wonder if there is any dialogue between the folks at Adobe Consulting and the UM team to see if some of the extensions can be incorporated into Cairngorm. My overall feeling is that although Cairngorm is opensource and there might be reaction from AC to the questions asked, the suggestions made about “improving” the framework often do not lead to action and that is I think what bothers me the most. With all do respect, but to me AC is too defensive about changing Cairngorm and that is what causes people to write and release their own extensions, or even start new frameworks. I’m certainly not saying that every little extension should be incorporated since it will only lead to a wildgrowth, but at least an effort should be made to engage some members of the community and let them have their say. I thought there was a Cairngorm Advisory Committee, but I don’t know if it still exists.
August 6th, 2008 at 1:18 pm
Christophe; here’s the announce I promised….
Be sure to follow the link to Alistair’s blog as well.
http://weblogs.macromedia.com/swebster/archives/2008/08/cairngorm_3_-_a.html
Hopefully this will give some sense of what has been going on; we’ve been taking a step backwards so we can take many steps forward in collaboration with the community. We’ve been engaged with the guys at Universal Mind, with Eric’s AIR extensions, and with numerous customers and partners who also want some mechanism by which they can engage more directly in the direction of Cairngorm, and opensource.adobe.com was the obvious platform upon which we could achieve this.
We hear you. We really do
August 7th, 2008 at 1:22 pm
Hi,
I used both pureMVC and Cairngorm in multiple projects. It worked ok, but we decided to build our own layered architecture which fits much better our needs.
Problems I have with Cairngorm: – Commands(Transaction Scripts). This approach works fine if your application doesn´t get to big. As soon as you have 20+ Event Command pairs automatically, especially in big teams, code is duplicated and spread out over multiple not well structured classes immediately. Singletons, ModelLocator classes and so on -> They are absolutly not the right patterns if you need to implement unit tests and have to be quality focused in your development. Especially if you have quite big rich clients a more domain driven approach is more suitable at least for our cases. A clean speration of your concerns (e.g. presentation layer, domain layer, infrastructure layer) also will help you a lot when developing in big teams (5+). We are currently working in a team of 12 Flex-Developers and this approach already saved us lot of time and troubles during development. Just my 2 cent on this
August 11th, 2008 at 1:40 pm
I found it to be good for most things, but I solved all my issues by extending it to create my own framework that I called CSK. Now it does everything I want it to do
Why wait for someone else to do it
Adobe provided us with a good slim framework but it’s not for everyone and it might not be perfect but there is nothing stopping anyone from making it better for your needs.
August 12th, 2008 at 12:41 am
Hi, i agree on most of the posts above. Therefor on the project we use right now we combined prana and um cairngorm.
We wrote our own “bridge” wich basically extends som um cairngorm classes and we borrowed some nce concepts from them to create our own frontcontrolle/modulecontroller. I really like prana but the cairngorm extensions included are overly complex imho.
to summarise:
- use prana for creating commands/models/delegates/services/command-event mappings
- no more service locator
- no more modellocator
- inject model/delegate into command constructor
- inject service into delegate
- populate frontcontroller via prana
and make use of the event generators of um cairngorm as well as the callback mechanism to the views. Let prana manage the object ifecyles (no more crappy code for singletons whohooo!)
all set! A nice clean approach
now we have the basic architecture running we have to thourougly test it, but it seems to work very nice!
Christophe, we mailed before about prana. If the project goes on and the people i work for allow me i’ll show you some code. Maybe i can then finally contribute to prana…
keep up the good work!
August 17th, 2008 at 12:40 pm
I just read http://weblogs.macromedia.com/swebster/archives/2006/08/why_i_think_you.html and http://www.adobe.com/devnet/flex/articles/cairngorm_pt1.html from Steven and I think they summarize the whole discussion about Cairngorm. I think that if you start programming it’s more interesting to program some design patterns your own instead of using frameworks like Cairngorm. In my opinion Cairngorm is often just overkill and used in projects where it really isn’t necessary to be used. If you have customers and deadlines, then finding a balance between rapid development and good code (using for instance frameworks) is very important.
If you are a good programmer and analist, then you need to be eager to learn design patterns, frameworks, other languages, … but more important learn when to use them and when not to use them.
@Herre: Thx for the sweet words on SminkedIn! You in Kortrijk Tuesday @ 12 o’clock? Belguim – Nigeria… We’re still looking for a TV…
Cheerio!
August 22nd, 2008 at 9:42 am
Christophe,
Have been flexing again and one of the biggest issues I have with Cairngorm or with the pattern is that my command is somehow slave of the view for which it is made. If a Command alters a model that is binded to a certain view, then the Commmand is actually changing the view. It doesn’t seem right. If another part of the application would use the command, then this view would also be changed… The Command should really notify the view that triggered the Command…
Are there articles on this because surely I’m not the first one with this issue…
Yow, Lieven Cardoen
October 25th, 2008 at 10:24 pm
Interesting how that Cairngorm update Steven Promised us in August does not seem to be there? Or maybe I overlooked it when searching on “Cairngorm” on blogs.adobe.com ?
October 25th, 2008 at 10:26 pm
Forget my previous comment – I just saw the link.
June 29th, 2010 at 7:16 am
the post is too old but hope I can catch with the newbies looking for better framework.. Cairngorm is SUCKS, if you’re planning to learn this stupid framework better not to do it. Its a waste of time, the approach is unacceptable.. what the hell using a lot of singleton with binded data on it. If you like a miserable development then go for it.
December 17th, 2010 at 8:49 pm
Cairngorm is too bloated in my opinion and takes far too much boiler plate code to get it working. Having a central dispatcher to commands for all events limits you if you want to import child modules that also use Cairngorm. Forcing you to centralize everything limits the components you can add, and adds a bloated mess of code.
I recently switched over to Swiz 1.0.0 which was just released. It is much much lighter weight and requires far less boilerplate. I’d highly recommend switching over.