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.