Anatole: It depends on the application you are building. Frameworks provide a higher level of automation and abstraction for specific tasks and with various coding and performance costs. For example, a Flex framework has Data Management Services for distributed Web applications. However, this model has limited applicability for simple Web applications working with an HTTP forms-based back-end API. You’d need a symmetrical MVC API on the client side. You can also have a client-side only text editor application, for example, that is completely “out of scope” for a Flex framework but would benefit from implementing a Command pattern. The real question is to identify the functionality you need, and then see how it is implemented in the appropriate framework

Yakov: I looked at the Cairngorm’s design and I'm having a hard time figuring out why would I need something like this? Okay, you may say that it helps to organize your project better. What else? Without any disrespect to creators of Cairngorm, I can't find any justification to recommend it to my clients. One of them has invited me to lead an ongoing Flex project, which is being developed by a large team of developers. The project uses Cairngorm, and also consists of a number of modules.  After reviewing the project, I've recommended they stop using Cairngorm. Without going into details, these are some of my concerns in this case:

The client wants to use modules, which can be loadable/unloadable. But since you are forced to use Cairngorm's singleton model locator, it'll keep the hard references to the modules (event listeners), which won't allow you unloading  modules. So, on top of Flex modules' memory leaking (yes, they leak), we'd introduce another memory issue.

Anatole: In many cases, a detailed look at the implementation will either get you on board or will remove the framework as a not applicable implementation. In later releases of Cairngorm, you can have weak references - so it works - at least theoretically. However, with modules there are quite a few places when unloading will become impossible due to legitimate code generated by a framework. In general, if you are going with modules, you need a multi-layered framework and intelligent registration services that are written specifically for the task.

Yakov: As far as I know, the use of Cairngorm was never approved by the Adobe Flex team, but I might be wrong here. The Flex framework is built on a nice distributed event-driven architecture, but Cairngorm is forcing your events to go through another singleton - event dispatcher. Why is that? Why does every view have to register the event listener in a central place? Now developers on a large project have to acquire additional skills in the proper usage of this framework.

Anatole: The reason for the use of global event listeners registration are derived from the size / type of applications the framework developers worked with.  It "simplifies" the project management by providing structure and separating the developers responsible for the model, view and controller into separate entities. All these singletons and managers are a way to establish a non-UI but business communication between parts.

Yakov: Do we really need global areas? Why not do it locally when needed?

Anatole: First, you need to look at the events. In most cases, these are not UI or input events but rather some application/state changes that need processing. The model is global, and the application events are defined on the global level.

I think most of the seasoned developers with a UI background are uncomfortable with this approach. You might want to consider Joe Berkovitz's MVC approach as a middle ground between Cairngorm and our component-based approach that might work better for medium to large-size teams that would have no access to code generators and data driven/factories-based architecture.

I recall two framework-related sessions at MAX’07, where approximately the same number of people were asked the question: How many of you have looked at Cairngorm?  Seventy to eighty percent  raised their hands during the Flex framework's BOF session and 90% on the Best Practices session. During the Flex framework session people were asked a second question,“ How many of you would use or actively oppose Caingorm?“ This time they’ve got a 50/50 split.

Yakov: I hope to be able to attend MAX 2008. So all these people came to the Best Practices session to get reassured that they are doing the right thing? But I’d really want to see some concrete examples where using these frameworks would bring technical benefits. I want to stress, I'm not talking about self-contained components that would automate some tedious job but a framework on top of a Flex framework.

Anatole: I think the main benefit of any pattern library will be based on its applicability to your application. There are quite a few applications – including infamous “shopping cart” ones – that can be coded quite efficiently with any of these frameworks. On the other hand, the extra setup code provided for “flexibility” is ironically the least flexible part of it.

As far as the benefit ratio between an architectural framework and smart components, I think you might want to try a little test. Ask any developer if she wants an architectural framework that still would require her to implement a DataGrid  componment (she would be allowed to use Grid components or some other low-level controls as a superclass). On the other hand, offer her a DataGrid component without any framework. I think this developer would recognize the importance of smart objects and go with a DataGrid. Take it a level deeper and you will see “extra” code in a DataGrid , and we’ve successfully overridden it in our own DataForm,  SuperGrid, and controls.

Yakov: Don't forget though that we are enterprise developers and are mostly concerned with a boring thingy called data processing. There are legions of Flex developers who do not care about the DataGrid. They are into the creation of cool visual components. But these guys don't need any frameworks either.

Here's another strong statement from the PureMVC framework, "The PureMVC framework has a very narrow goal. That is to help you separate your application's coding concerns into three discrete tiers: Model View Controller".

But isn't this goal already achieved in the Flex framework?  Wouldn't a simple separating the views, controllers and models into different folders of your project suffice? In many cases the role of Controller in Flex is kind of blended into the model (bindable data collections can emit and listen to events caused by some data changes). In some cases, if your application's views have reusable business logic (i.e., validation or connection to a specific back-end data feed) you may create separate controller classes that may be shared by more than one view. But this should be done on a case-by-case basis, and not as a must for the entire application.

Here's another statement from a well-written PureMVC documentation: "Making a separation of Model, View and Controller interests eliminates the most harmful responsibility misplacement issues that hamper scalability and maintainability". My English is not good enough to understand this phrase in its entirety, so can you play the PureMVC advocate and suggest how PureMVC would improve Flex scalability and maintainability?

Anatole: Well, there is an old saying that life is a play, written by God, and directed by the Devil. By making the process more formal you can build a lot smaller chunks, communicating a specific way, and in your mind the more formal process will yield better maintainability. On the other hand, it will create more parts to maintain and less flexibility to do so.

Yakov: PureMVC uses mediators, which is a very applicable pattern for the software that produces a UI. But would it be that difficult for developers or project architects to apply the Mediator pattern while designing their business applications as opposed to relying on a framework that implements a Mediator globally? Check out this blog on using the mediator. Is it so difficult that it has to be hidden into a framework?

Anatole.  ActionScript 3 makes a lot of patterns excessive. A lot of things can be done by using events or dynamic code without really breaching good programming practices. One-liners work for me as long as they are simple and concise.

The main question remains, “Do you want to use intelligent objects that encapsulate most of the framework's functionality or do you prefer to deal with simple objects and do explicit coding for each instance?”

Yakov: I prefer using self-contained loosely coupled objects.

Anatole: Coming back to your question of system-wide singletons…  I don't see any reason to create global objects - they are really bad for both application development processes and maintenance in the long run. You can have a singleton pattern inside the models themselves or bind location services with module loaders depending on the architecture of your application.

I've seen these frameworks being used mostly as a means to providing a project manager/architect with the ability to separate areas for developers, quantify functions and make projects more manageable. The effect for the resulting application will most likely be negative, but it is a very straightforward approach to building systems.

Yakov: So you are saying that utilizing a framework on a project allows you to create and enforce a nice-looking project plan that reads, "Mary will create 10 model objects by February 1, and John will be done with his views a week before?"

Anatole: Yes, and then we will have all the commands coded a week after that and then we will think about fitting it all together, essentially moving real architectural and design questions toward the end of the project. If you answer the question “How?” first, people tend not to ask “Why?” for quite some time. On the flip side, you will have people doing their parts rather quickly, thus producing an enormous amount of code to fix when the design problems become evident. The problem with formal coding techniques is the human-generated code (thus cut/paste errors) without the ultimate understanding of how it will be used and very little testing done while writing the code.

Yakov: In the U.S., we are already accustomed to protective medicine, where the main goal is to ensure that the patient won't sue you. So when a guy with a headache shows up in an emergency room, they start by sending him to an MRI and making tons of other not too necessary tests. But, it’s better to be safe then sorry... The same rationale here - it's easier to CYA with a nice project plan (see www.acronymfinder.com for the definition of CYA).

Anatole: The problem starts much later - at some point in the project the spec changes - the business analyst realizes that mistakes were made, the process changes, the other departments need some of your functionality or another line of business has to be handled. There is no time compression or shortcuts available there - commands need to be amended and recoded, views redesigned, events integrated with a different workflow. You are now thinking to yourself, “Why, oh why, did not I go with an application framework instead of the architectural one?”

The application framework's goal is to get you through the "implementation" part faster while providing maximum flexibility with the design and functionality part. If you don't have 80% of the application built in 20% of the time, you will be late with the last 20%.

Flex is more of an application framework. It is not a library of patterns but rather a set of objects that are built to communicate and react. Flex uses code generators and other behind-the-scene techniques to achieve that. The key here is the automation of implementation tasks by minimizing the amount of code while behaving predictably. That is done by explicitly checking the "related" objects for specific interfaces. By not adhering to the implementation of these interfaces, the external frameworks require serious application development effort to support them.

MVC principals are also questionable in the Web2.0 world. The concept of fine granularity and validation on the client has serious security implications. You go to any AJAX show and you'll see one or two sessions with security specialists, cracking AJAX sites, getting free airline tickets, buying things for one penny, etc. It seems that every serious organization should be more interested in the distributed model rather than a pure client-side solution. In that case most of the benefits of global MVC go out the window.

Yakov: So far we have just a couple of the third-party Flex frameworks, but the creation of the new ones is a viral thing, and the last thing I want to see in the Flex community is more than a hundred frameworks that do the same thing. We already see it in the AJAX world.

Anatole, it’s not easy to quarrel when both parties share the same views. We really need other people’s opinions to better represent Flex developers who may see the benefits of using frameworks.


Yakov and Anatole work for Farata Systems, the company that specializes in architecting Flex/Java projects, developing custom components and Flex training.