When is Cairngorm too much for a Flex 2 application?
Last week I ran into a great deal of resistance to using the Cairngorm Microarchitecture with a medium-sized Flex 2 application. The project itself was going to be separated into three applications: a login application, an administrative application and a user application. The admin and user apps had several screens and some fairly complex components on it. The back-end is Web Services-based. In my mind, this application is a true candidate for Cairngorm.
Now, I have to admit that the reasons given to describe the resistance seemed rather short-sighted and misinformed — "it's over-kill for an app this size" and "I hate having to go down three folders to get to the code." At least, those were the only complaints that were offered.
So, I thought this might be a good time to ask the question in this public forum and see what others may think: When does using the Cairgorm Microarchitecture make the most sense? Is Cairngorm only for the super-sized apps? Or does the best practice of using Cairngorm with anything bigger than an application that has two forms still make sense to Flex 2 developers?
What is the Cairngorm Microarchitecture?
To quote the Adobe Labs Wiki:
"The Cairngorm Microarchitecture is a lightweight yet prescriptive framework for rich Internet application (RIA) development.Cairngorm is an implementation of design patterns that the consultants at Adobe Consulting have successfully taken from enterprise software development (with technologies including J2EE and .NET) and applied rich Internet application development using Adobe Flex."
So, perhaps that doesn't make a lot of sense to an uninitiated developer. To put it more simply, Cairngorm allows for teams of developers to create code that provides clear separation of model, view, and control layers, is easily maintained, uses established design patterns that makes events — both within the application and between the application and server — easier to create and manage.
Surely, using Cairngorm would not be recommended for a one or two form application. But even so, there are good reasons to use Cairngorm.
Standardization of Folder Structure
Yes, when you finish setting up the Cairngorm Microarchitecture there ends up being a lot of folders. But isn't that one of the points for using any framework (not just Cairngorm) — a standardization of structure? When working in a team environment, establishing a file architecture is essential for efficient and maintainable coding. Sure, you can create your own framework, but look at Cairngorm's file structure; if it isn't very familiar then you haven't been developing for very long time — Cairngorm uses tried and true best practices found in Java and .Net frameworks.
Event Architecture
You may use the event architecture native to Flex 2.0 to create, dispatch and consume user gestures as well as communicate with the server. That is why that architecture exists. But the Cairngorm Microarchitecture expands this native functionality to assist the developer by encapsulating both user gestures and system-level events into one structure.
Cairngorm uses the Service to Worker design pattern, which is a combination of the Event Dispatcher design pattern, the CairngormEventDispatcher, and the Front Controller and View Helper design patterns. Yes, that is three design patterns being used together, which is not uncommon, and can be difficult for an inexperienced developer (and often experienced developers) to get their head around.
Ease of Maintenance
When working in a team environment, developing maintainable code can be a real challenge. Using a framework resolves a great deal of the challenge by establishing where specific types of files should be placed along with providing guidelines for development. The rest of the challenge comes from making certain that all the developers follow those guidelines.
The best example of how using the Cairngorm Microarchitecture makes maintenance easier is the "commands" folder. It's the folder where all the communication to the server happens. Suppose there was a change in the server-side code that makes it necessary for a change to be made with the command that calls that method on the server? Who can make that change? Well, anyone on your team. Basically anyone who has the most basic knowledge of Flex can find the folder, open the command file, make the change, recompile the application and test it.
In fact, I would recommend that team managers assign junior members of their teams to preform maintenance as a way for the junior members to become accoustomed to the Cairngorm Microarchitecture as well as to see what other coding guidelines have been established.
Back to the Question at Hand
If you are considering using, or in this case not using, the Cairngorm Microarchitecture, perhaps you should first take a look at Steven Webster's blog posting "Why I think you shouldn't use Cairgorm." Steven is one of the people that is responsible for Cairngorm from a time before he became an Adobe consultant. His advice is sound.
To answer my original question, Steven suggests you should count your user gestures:
"So what exactly do I mean here? I'm trying to measure the complexity of your application how many different things can the user do with your application, that merit some computation being performed on the client or server. Viewing all products in a catalogue is a use-case. Adding a product to a basket is a use-case. Deleting a product from a basket is another use-case. Taking the basket to the checkout is another use-case. Checking out is another use-case. Ad infinitum. If your application has several use-cases, then the organisation that Cairngorm will bring to your source-code becomes valuable."
So, if your use-cases total more than, say, two then you are building an application big enough to use Cairngorm. Of course, that comes from Steven, who has a biased opinion about Cairngorm, but with several enterprise-level applications deployed he has the experience to back that up. My experience tells me something more: if your use-cases total less than two, you aren't really building an application. You are building a form.
Further Cairngorm Reading
The Cairngorm framework is not something that you should enter into lightly, especially if you have never used a framework.
It would be a mistake for me to not mention Steven's five-part introduction to Cairngorm, written back when Cairngorm .99 was around, should be required reading for anyone who is starting to use Cairngorm. In fact, on the CFlex site, Tim Hoff said, "I read the entire article series front to back, probably 4 times, before everything sank in." I might go as far as suggesting that, if studying the sample application and documentation at Cairngormdocs.org doesn't get you on your way, perhaps it might be necessary to find a good counsultant or contractor to get your internal staff off on the right foot.
Comments (4) | 
Print | 
Send |
del.icio.us
| 
Digg It!
| 
Linking Blogs5138 Views
Comments
For those of us in the Flash world, where our projects typically took 2 to 3 weeks, and sometimes a lot less, _root contained all controller code, and hopefully most of your data calls as well as model updates. It tend to be bloated, but at best, was a few functions that "ran everything". Most of these couldn't grow very big as there were direct links to views, and race conditions were ripe when View's changed. Quick, easy access to code, and agile. Couldn't scale fer jack.
Joe's methods really embody good practices, and effective use of patterns. His Controller and Service are really the more higher level things that to me, make it a framework in that you use those and play their rules. There are a ton of things that make his way not as scalable as Cairngorm, though, which I'll have to blog about once my DNS changes propgate later in the week. Suffice it to say, his Controller setup won't flex well compared to Cairngorm events. Controller functions have a set parameter order; Cairngorm events don't. Changing a Controller function makes have to suddenly change all View's who used that function. You don't have that problem with events since there is no "order". If one particular view needs a property added to the Event so the Cairngrom Command has context, so bet it.
...however, Joe's way saves you the hassle of writing Event classes AND Command classes PER use case. Instead, you write a function, and call it. Simple, quick, easy.
Further, Joe's Operations do too much work. Data set in the model, getting & parsing of that data are 2 different things; the former should not be with the same person who gets it, hence Commands and Delegates handling those responsibilities. Delegates shield everyone from a back-end change, and you can have your Factories in your Delegates pump out fake VO's, and your Commands don't know the different.
...Joe's has less classes, though, and commenting out a few lines to pump in fake data isn't so bad.
Ok, this will take too long. Bottom line, here's what's worked for me:
1. Using Application.mxml as the end all be all controller & data getter of my app has worked for "forms" as you put it as well as testing simple crud operations with a few small views to see if a specific CFC, PHP class, or Ruby controller is functioning correctly and I'm getting and sending the data I need. Using any framework, interface, or "encapsulated" anything is ridicolous. I'm testing stuff, or making a demo; back off, I got a deadline.
2. I used to use Joe's way in Flash, although, my best practices probably weren't as good as his ( I never used interfaces, didn't really encapsulte my views much, and definately had global grab bags). Bottom line, any Flash app that had a 2 month or less deadline, and was interacting with any form of back-end had this. It allowed me to create my View's, write some test FLA's to test the back-end data, and in the end bring them together. This worked well with a few classes to help "clean up the mess" on _root. Since View's and back-end service classes were usually the most changed and worked on classes, this type of controller worked well; additionally, since it had View responsbility, I was usually the only one touching the Controller code.
3. Anything else? Use Cairngorm. I'll admit, I have Cairngorm / ARP goggles on. It's nigh impossible for me to see how you can succeed on any medium to large scale application with 3 or more developers. The word medium is a crock given that most software always exceeds it's lifecycle, and ends up being bigger than you thought anyway. Even demo's or prototypes that "accidentally" become true products by upper management's decree will all be safe if you start right in the begginning.
People saying "digging through folders to get to code" sounds just like me 5 years ago when I wrote 100 lines of ActionScript in Flash 5, and immediately felt dizzy and had to go smoke 2 ciggarettes. They'll get over it. If they don't, feel free to watch them sweat as they try to manage their sphaghetti code 5 months later.
http://www.adobe.com/devnet/flex/articles/blueprin...
I'm building a flex based dashboard, the prototype is just 3 reports with charts, and with me training 2 other guys in actionscript 3 I didn't want the complexity of cairngorm so I borrowed some of the classes are wrote for arp (arpx) and updated them for AS3, after about 2 weeks I found the app was getting too unweildy and things felt disorganized and I refactored into cairngorm, as such it feels much smoother and cleaner now and I don't feel "fuzzy" about where to make changes when there is a big.
I have to admit I'm a pattern junkie when it fits and I think I'd be hard pressed to find a case when cairngorm doesn't fit, or some other MVC pattern.