I don’t agree with your shantytown analogy. I live in the area where you can find very nice looking development with buildings that look alike, but the nicest developments are those where each house was custom-built. While a framewtork allow some freedom of programming, the best result are achieved when an application uses only those building blocks that are needed for this particular application.

I can’t argue about pureMVC as I did not have a chance to use it, butwell-designed framework/class library should seemlesly blend into your application. When you look at the application’s code, you should see…the application-specific code, and not model locators, delegates, commands, etc. This is definitely not the case with Cairngorm.
I’ve joined one of my current projects too late in the game. It consists of 20 separate Flex modules and uses Cairngorm. The code looks convoluted and unnecessary heavy. I do not allow using Cairngorm for development of the new modules for this application. I’d be happy to remove Cairngorm completely, but it turned out to be an expensive project.

The reason I wrote PureMVC was so that people without a lot of design pattern background could be given a set of patterns and a recommended program structure that solve the MVC problem without it having to be cooked up from scratch on every application.

There’s nothing wrong with building something from scratch, just ‘doing whatever works’, but the problem is that 6 months later you yourself may not remember what you were thinking. And given the common developer’s lack of documentation discipline, it’s unlikely that ‘whatever worked’ was actually documented.

So 6 months later when a totally different developer approaches your code, if they know the framework, then they only need to understand the problem domain to make immediate progress. A quick survey of the app will show everything is in place and doing what one would expect and you get on with extending the app. This is where the case for maintainability is made.

Over the last year, I’ve looked at a lot of applications written in PureMVC by other people and – surprise – they usually look exactly as if I had written them myself. There is a lot of benefit to be had in having a well-defined methodology for the core organization of an app.

Think about where Design Patterns come from. We stole them from ACTUAL architects – people who draw up the blueprints for the buildings we live and work in. Now consider if the home you are living in were NOT architected AT ALL. The builders show up with some materials, have a look at your land and start hammering away. Depending on the skill of the builder, you might end up with something that’ll keep the rain off, but wouldn’t you feel safer in a nice well-architected house? One where all the major issues with home-dwelling had all been taken into account and handled with tried and tested methods (architectural patterns)?

Scalability is also enhanced because the way to add new use cases to the system is clear. In a system without a sound architecture, the way to add new functionality (without breaking the old) is not always so clear. To return to the un-architected house metaphor, if your house wasn’t architected, and furthermore, neither was your town, then adding new houses and getting to them would be, well, a shantytown: http://www.laputan.org/mud/mud.html#BigBallOfMud

Here’s an everyday issue with civil hacking without patterns that you’ll be familiar with.

Do you know how sometimes you walk up or down a set of stairs and they just feel wrong? You look at them and they seem well built, maybe even covered with granite, and nice little sandy footgrip pads, but still when you walk those stairs you feel weird? The step is too long or not long enough, too tall or not tall enough, somehow you stagger up and down them, cursing whoever built them. That’s because the builder / architect completely failed to apply the 7/11 Stair Pattern. Seven inches up, Eleven inches out. That’s just right for most humans and its the pattern for most stairs. Except the poorly architected ones.

-=Cliff>

I have to agree with Anatole that a framework can help define a structure when working on a team. To answer the question, I think a third party framework can provide structure, definition and solve some puzzles developers face but I think they are too much overhead for many projects. I do not have time. I can write something clean and precise without following a framework. What I would like to see is more structure and best practices for the existing Flex framework.

Are you totally against application frameworks in the flex world, or are you simply against the ones present now? Maybe it is because there isn’t one yet, that satisfies your needs? If this is the case, maybe, by making clear (a) what you don’t like in the existing and (b) what you would like, could start a movement for a better flex framework!?

You came from a Java world that has about 50 Web frameworks, and so did I.
But I believe that Java Struts framework is bad, and when I see all these Flex frameworks that are built around MVC, it\’s clear to me that they were created by a former Java Struts programmers.

Please try to forget Struts, think more loosely coupled Spring, if you can\’t live without a framework.

There are tons of ways to combine the library classes and tons of ways to organize the source code of flex applications. Guidance can be a good thing, which you can get from a framework. Now, I have not myself used a flex framework yet, but I will be having a look at PureMVC. Maybe I like it. Maybe I don’t. Maybe I shall then look at another. I come from a Java world filled with frameworks. Sure enough, there are some good ones, but there are also lots of not-that-great-ones (again, to me, that is).

I think it is a good thing with frameworks on top of flex (which is not an application framework in itself).

I grant the possibility, however remote, that Cairngorm, et al have a useful purpose but never, ever in Flex example code, unless the example is of the framework itself.

Yakovs point is more of “why get a cow when you can have milk for free”. Why do I need extra framework with a lot of duplicate functionality to the Flex one? Why do I have to do all manual labor of wiring and configuration instead of objects falling into places themselves and registering themselves by taking advantage of Flex built-in code generators**? Should we just treat patterns for what they really are and package them in the way we package other reusable objects? Should they be parallel framework or rather extension (or even aspect-based override) of the existing ones? Can useful patterns be that simple? Why I need global objects if I build modular application and most of my events are local? What is wrong with registration and broadcasting events via standard extensible singletons like Application?

Very few new developers think of Flex as framework. Simple fact that demos/samples work “somehow” by falling into internal communication patterns seems so natural that the question “how” is never asked. Binding, event notification and delegation are pre-built and code generated based on the tiny little metatags we place automatically – and it just works. Another loosely bind framework is CSS implementation. You place objects, apply “CSS” and the behavior/presentation chages – across multiple objects. Again – code generation and pre-built functionality work miracles. And Flex is rich with patterns that like class factories – it is foundation of the current release and becomes more profound with Flex 3 and Thermo. If you master and dynamic resources they provide solid foundation for customization and wiring in any imaginable way.

The only benefits of “structured framework” approach I can see are in the areas of project management ( well overshadowed by consequences I have seen when asked to take over failed projects – see my answers to Yakov) and some applications closely matching the ones used as testbed for the framework itself – if you think sample application does what you want to do and scope is similar – go for it. If the main reason to go with architectural framework is lack of Flex knowledge and it comes with samples/there is a lot of code – use Steven’s guiding principles “When not to use architectural framework”

Regards,
Anatole

*Application frameworks are essentially applications stripped out of some implementation details and generalized in the places that are most likely to be customized. Indeed, for your application skeleton you want something similar in size and shape – starting “fish” with “girafees” skeleton is going to be challenging at least. With a good fit though, you can have “working” app much faster – even with time for adoption and training

** Look at the compiler output to see all the initialization code Flex generated for you – why not use metatags and code generators? Hopefully, with Flex compiler going open source this week ( I believe Adobe mention end of the year in their May press release) most of our code generators can be rolled in. From the management perspective, I firmly believe that writing tons of code should be banned in most of applications.

As to why you would want multiple frameworks for an application (or development platform), think briefly about what a framework really is. It’s a library of pre-written code that provides services for your application, and a library of recommeded design patterns for interfacing with that library of code. Looking at things this way, the Flex Framework, isn’t so much a “framework” as a base Object Library, similar to the .Net API, or the Java API, or even the old school Win32 API. Just because we’ve applied the word “Framework” to the Flex core API doesn’t mean that we don’t need some other code or design pattern libraries to build a complete application. You can start building a .Net application using just the Windows.Forms API, but as soon as you start moving outside of the trivial applications, you’re going to start needing an architectural framework to decide how to lay out your code, and a unit-testing framework to prove that your classes are providing advertised functionality.

These frameworks aren’t being created just because someone has too much time on their hands, and can’t think of anything better to do. They’re being created because they fulfil a need. Each of them provides a service that the others don’t, or a combination of services the others don’t. You don’t (and shouldnt need to) know all of them, or use all of them, and you definitely shouldn’t be recommending them to clients or refusing to recommend them to clients. You should be familiar with what problems each of them solves, and use them when appropriate. Cairngorm isn’t suited to every single Flex Project. PureMVC isn’t suited to every single Flex projet, nor is Model Glue Flex. However, sometimes one or more of them is appropriate. Being familiar with when each is apprpriate is tough, but a worthwhile exercise.

I’ve been doing object-oriented programming during the last fifteen years, but I’m not in love with it and would rather not see frameworks created just for the sake of OOP. But this is a whole different discussion altogether.

I’ll let the rest of the community respond to your post; my thoughts are already laid out as to when you should and shouldn’t use Cairngorm, I don’t believe a black and white answer is the answer, and I’ve always took the position that if it works for you use it (and it works for many people) and that if you have preferences to use something else or something you consider more fit for purpose, then that’s a decision any good developer is capable of making on their project.