This started as a Skype chat room conversation between my colleague Anatole Tartakovsky and myself, and I thought that it would be a good idea to invite more Flex developers to this discussion.

Having said this, I “d like to make it clear that over my career, I “ve been developing frameworks and truly respect people who are capable of creating frameworks, and Anatole has huge experience in this area as well. Here we “re just questioning the need to create frameworks not for a general-purpose language like Java, but for a domain-specific framework like Flex.

This is our dialog with minor editing. Your input and feedback are greatly appreciated.

Yakov: Why do people design Flex frameworks as opposed to reusable components? One of the framework is called Cairngorm, the other one is called PureMVC. I “m sure there is more. It seems to me that such frameworks are unnecessary overhead over well-designed Flex frameworks. Are there any benefits here? Why bother creating all these singleton-based bottlenecks?

Anatole: First of all, PureMVC seems to be more of an ActionScript Framework. It is not specifically a Flex framework and concentrates on the task of creating a generic framework for low-level AS objects. Flex comes with “prebuilt suggestions rdquo; of how a model/view controller might work – and it offers lots of hooks throughout the data and UI classes that help implement MVC.

PureMVC is also “server-agnostic “. Flex made the Java implementation of a distributed Model that can provide dynamics to the distributed Web applications very efficient. PureMVC is more about making apps in a more traditional way.

Cairngorm was started as “Micro ndash; Architecture rdquo; ndash; a set of patterns that allowed the solving of certain problems in the application design ndash; like Model Locator or Commands ndash; and certain applications. It never appealed to me as it had a number of assumptions that required more coding. At best you would use one or two pattern implementations from Cairngorm, but it “s much easier to rip out the part you need and adjust it to your liking.

Yakov: I can appreciate the fact that design patterns are useful in general, because they may help developers deal with repeating patterns in software constructions such as Singleton, Mediator, Model-View-Controller and the like. But when I look at some of the third-party frameworks built on top of Flex, I keep asking myself the same question, “Why build a framework on top of a framework? Are there any benefits to introducing a middleman between an application ‘s views and an already existing Flex framework?

Anatole. It depends on the application you are building. Frameworks provide higher level of automation and abstraction for specific tasks and with various coding and performance costs. Fo example, Flex framework has Data Management Services for distributed Web applications. However, this model has limited applicability for simple Web applications working with HTTP forms-based backend 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 rdquo; for Flex framework but would benefit from implementing a Command pattern. The real question is to identify the functionality you need, and then to see how it is implemented in the appropriate framework

Yakov. I looked at the Cairngorm “s design, and having hard times figuring out why would I need something like this? Ok, you may say that it helps to organize your project better. What else? Without any disrespect to creators of Cairngorm, I can ‘t find a justification to recommending 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 at the same time it consists of a number of modules. After reviewing the project, I ‘ve recommended to stop using Cairngorm. Without going into details, these are some of my concerns in this case:

The client wants to use modules, which are 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 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 framework. In general, if you are going with modules, you need 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 Adobe Flex team, but I might be wrong here. 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 every view has to register event listener in a central place? Now developers on a large project have to acquire additional skills in proper usage of this framework.

Anatole. The reason for 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 developers responsible for 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 doing 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 UI background are uncomfortable with this approach. You might want to consider Joe Berkovitz MVCS 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? 70% -80% raised their hands during the Flex frameworks 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 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 ndash; including infamous “shopping cart rdquo; ones ndash; that can be coded quite efficiently with any of these frameworks. On the other hand, the extra setup code provided for “flexibility rdquo; is ironically the least flexible part of it.

As far as 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 component 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 an “extra rdquo; code in a DataGrid , and we “ve successfully have overridden it in our own DataForm, SuperGrid and controls.

Yakov. Do not 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 creation of cool visual components. But these guys do not 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 Flex Framework? Wouldn ‘t a simple separating 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 model itself (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 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 the case-by-case basis, and not as a must for the entire application.

Here ‘s another statement from a well-written PureMVC documentation: “Making 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 Devil. By making the process more formal you can build a lot smaller chunks, communicating and 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 UI. But would it be that difficult for developers or project architects apply Mediator pattern while designing their business applications as opposed to relying on a framework that implements Mediator globally? Check out this blog on using the mediator. Is it that difficult so 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 functionality or if you prefer to deal with simple objecst and do explicit coding for each instance? rdquo;

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

Anatole. So, coming back to your question of system-wide singletons hellip; I do not see any reason for creating global objects – they are really bad for both application development process 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 have seen these frameworks being used mostly as means to provide project manager/architect with ability to separate areas for developers, quantify functions and make project more manageable. The effect for the resulting application most likely to be negative, but it is very straightforward approach to build systems.

Yakov. So you are saying that utilizing a framework on a project allows 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? rdquo; first, people tend not to ask “Why? rdquo; for quite some time. On the flip side, you will have people doing their parts rather quickly thus producing 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 how it will be used and very little testing done while writing the code.

Yakov. In the USA, we are already accustomed to protective medicine, when 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 with 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 http://www.acronymfinder.com for the definition of CYA).

Anatole. The problem starts MUCH later – at some point of the project the spec changes – business analyst realizes that mistakes were made, process changes, the other department needs 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 re-coded, 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? rdquo;

The application framework goal is a way to get you through the “implementation ” part faster while giving you maximum flexibility on design and functionality part. If you do not have 80% of application built in 20% of the time, you will be late with the last 20%.

Flex itself 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 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 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 distributed model rather then pure client side solution. In that case most of the benefits of global MVC go out of the window.

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

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 benefits of using frameworks.