Denver RIA Developers Group inspiring the Flex community

Personally, I say skip the frameworks.  I've used Cairngorm at two different companies and it's a nightmare.  Flex already has a framework built into it and uses many patterns such as Observer and Factory.  Adding a framework on a framework doesn't make a whole lot of sense.  If you put time in to design your system from the start, you really won't need an additional framework.

The best way that I've found to develop in Flex (or any language) is to simply practice good OOP skills and modularize/componentize your code.  I develop everything I write as a reusable component in a sandbox and then implement into my project code to make sure that the functionality is fully encapsulated.  It ensures that I don't end up with a bunch of spaghetti code.

Good luck.

Thanks for the feedback.  I was just read a blog on a simplified cairngorm -- easymvc.  Looks fairly straight forward and in a way a lot like the dir layout for RoR apps.

p.s. The main reason in looking for a framework (outside of just trying to understand best OO practices w/ flex) is they'll be at least 3 developers.

I've worked on a couple of nightmare cairngorm projects as well, but the problem was not cairngorm, rather, just crappy code in general. just because you use a framework doesn't automatically mean your application will be written better, for, it's just as easy to write a crappy cairngorm app as it is to write a crappy non-framework-using flex app.

Yes, flex is aleady a framework by itself, but cairngorm (and puremvc) are more of an architecture (flex doesn't have a built-in architecture, intentionally, as to give you the freedom to implement your own architecture... such as cairngorm for example) So, comparing the flex framework with cairngorm doesn't really make sense. Cairngorm is one of many ways to solve problems that the flex framework doesn't and isn't meant to.

Unless you're going to be working solo on everything you do, I highly recommend learning these frameworks. They are used extensively throughout our industry and in most of the big name shops, many of which is a requirement to even get your foot in the door. Even if you decide these frameworks aren't for you, a well established flex'er should at least be familiar with them.

As for comparing the two, I can't really comment since I haven't yet spent enough time with puremvc

I concur with Devin. I'm a fan of Cairngorm, for large projects with multiple developers. For a small one off job that you're the only dev, try it without, I probaby would. But if you've got a team of developers Cairngorm makes it cake for distributing work. It's very easy to wonder off into the brush in Flex on a large project with no architecture. Heck it's pretty easy even with one! LOL.

I'm on a PureMVC project right now, I'm sure it's partially bias, but it's not my cup of tea. The metaphors in Cairngorm, simply make a lot of sense.

I haven't tried easyMVC, I know the developer so I'm sure it's great. My next small 'me' project will probably see me trying easyMVC.

I agree that you should be familiar with frameworks such as Cairngorm as you'll certainly come across many projects that use it.  I don't agree that it's a good architecture, however.

My first complaint with Cairngorm is that it introduces numerous singletons (FrontController, ServiceLocator, ModelLocator).  The singleton pattern has its uses when used appropriately but it kills modularity in most application development.  For example, many developers use a singleton to store remote host information for their HTTPService objects but that assumes that all of your application uses a single remote server.  That may be the case in the short term but if you ever modularize parts of your application to use different servers then it becomes extremely difficult to decouple from a singleton model.

My second complaint is the global model (ModelLocator).  Tightly coupling all your code to a single model not only kills modularity but also makes that single class too knowledgeable about the application as a whole.  On top of that, ModelLocator isn't even a real GoF pattern.  The Cairngorm creators just made it up.  If you really want a singleton model, at least separate out the logical models into their own classes.

Lastly, I find that Cairngorm introduces a ridiculous amount of complexity into what should be fairly simple tasks.  To run something on the server you have to fire an event to the FrontController which executes a Command which calls a delegate which looks up a service locator which finally calls the server.  On the way back it must call the command which updates the ModelLocator which fires an event for the interface to pick up.  There's probably six files that you need to alter or create in order to add even the most simple functionality.  I think there are good places to use all these patterns but if your application doesn't require them all the time, then your application should be fitted for whatever is appropriate.

As far as architectural frameworks (Cairngorm) versus application frameworks (Flex), the line is thinning between the two.  Architectural frameworks provided facilities such as a controller pattern but now you can implement a controller via annotations (@Bindable).  Flex is a domain-specific language (client-side UI) so it lends itself to incorporating architectural framework elements into its base application framework.  A language like Java can be used across such as wide array of domains (back-end processing, database processing, embedded devices) where creating domain-specific frameworks can be useful.

 If you want to read some other good points as to why Cairngorm can come up short, I recommend reading the Farata Systems blog (http://www.faratasystems.com/blog.php).  They do a good job of articulating the pros and cons of third-party frameworks.  Search for "Cairngorm" and you can find a couple blog entries.

If anything, I would argue that Cairngorm should be used for small projects that do not need to be modular.  Anything larger should be architected based on the requirements of the project, which may or may not work with an existing third-party Flex framework.

Good points Ben, obviously this discussion weigh heavily into "to each their own". The Farata blog is good in general. There's also some good Cairngorm how to posts floating around as well. Same for puremvc.

I think the one benefit any architecture provides over "roll your own" is familiarity. " but now you can implement a controller via annotations (@Bindable)." Sure but then it has to be explained and learned by every developer that comes through the door. I worked at a place that wrote their own MVC framework/architecture... it was ok, but was a one off that had to be learned and wasn't applicable outside that domain. I think using (if you're going to at all of course) an architecture helps make growing the team a bit easier, especially if you're using a mainstream architecture like Cairngorm.

I agree 100% that Cairngorm adds a level of complexity to apps, since a single task is three 'things' I think that was one of the driving factors of easyMVC.

Ran across some recent diagrams that seemed timely given this month's framework meeting.

This link takes you to the PureMVC diagram and you can go from there:

http://flexblog.faratasystems.com/?p=345

We took a look at Cairngorm as well.  We also found that it took a lot of code to do a simple task.  It also reminded us of struts, so if you liked Struts it probably will be an easy transition.  The singleton model was the death knell for us.

We started playing with Mate.  It seems a lot more straight forward and the latest release is supposed to handle multiple model instances.  It's worth looking at:

http://mate.asfusion.com/

I'm using Flex and evaluating Flamingo and GraniteDS all of which interface to Seam and EJB3.  Seems to work well.

-robert.

As an experienced flex developer working on small and large projects, modularized and not, internationalized and not, I've found results corresponding to many of the previous comments.  Cairngorm is nice and is second nature to use once you've become accustomed to its intricacies.  An experienced OO programmer shouldn't have a problem understanding the micro-architecture on offer from Cairngorm.  

What I like most about this architecture is that it's there when you need it, and only when you need it.  If you abide by the best practices of Cairngorm (namely, only implementing it for async calls to the server and "massaging" data on return from server), and use extensions such as Universal Mind's CairngormExtensions for ease of Hook-ins and several other features, the architecture becomes much more usable.  

For small projects, and individual modules, Cairngorm might not be the right tool to use. Instead, think of creating a dumbed-down MVC system with a custom modellocator instance, services directory, remote objects getters  (instead of a services.mxml), and a custom callBackManager class.  This will ensure the best practices required by Cairngorm are implemented in your smaller applications, without the hassle of setting up Cairngorm.   I personally use a combination of Cairngorm and custom MVC setups, as well as common SWC libraries to deal with multiple applications / modules.  I also have no lack of singleton manager classes to keep modellocator small.  I pick and choose when and where to implement each, to fit the current project at hand.  

The point is to not immediately discount any system, as those like Cairngorm and PureMVC have been put together by developers who likely have thought about it more than you, if you're asking the question, and have put more thought into it than anyone else.  But I reiterate, it's still not a necessity, especially for individual, smaller projects. 

If you're embarking on a medium or large scale application, doing so without some advanced architecture system is only doing an injustice to your code and yourself.