Flex Architecture Fundamentals Part 4 : Architecture Frameworks

This post belongs to a four part series :
Part 1 Rich Internet Application Server Architecture Basics
Part 2 Main Means Of Communication Between Flex And The Application Server
Part 3 Designing the Flex application as a Model View Controller
Part 4 Using Architecture frameworks

In the previous part of this series, we've seen how design patterns could help us design a Flex Application. In particular, we've learned that it's considered good practice to divide our application into three parts : The Model, the View, and the Controller.

Today, we'll see how some Flex architecture frameworks can help us implement these practices. Please note that this is absolutely not a tutorial. There are great examples, blog posts, articles about these topics all over the Internet. It is not my intention to repeat what's already been said elsewhere, but rather to give a quick overview for the Flex developer who's wondering if (s)he should take the leap.

I've decided to focus on three main alternative you may have to choose from :

  • No third party framework
  • Cairngorm
  • PureMVC

There are many other architecture frameworks out there, but I think none are as popular as the two I've just cited. Most of them lack documentation, are at very early stage of development, or don't seem very well suited for Flex development. This might very well change in the near future, but as today, I think there are no other mature alternatives. Of course, I may be wrong, but you should be warned that I'm not the only one to think that.



No third party framework


A Flex framework centered MVC implementation, without any third party library. The idea is very seductive, but is it realistic? Can the Flex framework alone handle a proper MVC architecture?

Most Flex applications I've seen so far were designed as follows :

On one side, you have properly decoupled and reusable view components, that know nothing about the rest of the application, dispatching events and using databinding from parents and to children views.

On the other side, a main application container (the Application root tag) acts both as a controller and a model, sometimes delegating tasks to some "utils" classes that handle things such as RPC communications. In other words, a big God object, which can quickly take the form of a hideous spaghetti-code monster.




If your application is quite simple, and you're pretty sure you won't have to maintain it for a long time, this might be not such a bad choice. However, I strongly recommend that you (at least) take a look at other alternatives, just to be sure to know what you're missing.

Sometimes, you can also stumble upon little gems such as the one described in Joe Berkovitz's An architectural blueprint for Flex applications. Joe Berkovitz's article has often been mistakenly interpreted as some kind of "you don't need a framework" advocacy. The truth is that it implements its own, not so simple, MVC architecture.

My opinion is that the Flex framework alone does not offer the best tools to actually design a proper MVC architecture.

Using Events and dataBinding, Flex can acheive a very good view components decoupling. But your main view container will either have to handle all the logic by itself, or explicitely delegate it to a controller class with which it will then be very tightly coupled.

I think the main problem is that user interaction events dispatched by the views cannot directly communicate with a separate application controller, unless it is a view. To have a separate controller handle these events and take actions, the events have to climb the display list up to the main application container (the root application tag) which may then lead them to the controller.

Joe Berkovitz's example does not adress this problem. Its views have knowledge (indirectly, with the use of an interface) of the Controller, which of course creates coupling between the two layers and results in much less reusable views. Besides, he implemented a big Controller which handles all the application actions.

Like many, from the early days of Flex, I've tried to use my own recipes, in vain. So I stuck with my Main View spaghetti code monster for a while. And then I heard about Cairngorm...



Cairngorm


Cairngorm is probably the most widely used architecture framework in Flex applications. This framework was written by some smart guys at Adobe Consulting and is very inspired by J2EE patterns.

Basically, you create a controller by extending a FrontController class, and just put a bunch of addCommands(EventName, CommandClass), to associate events with commands. Of course you create one Command (a class that implements ICommand) per user gesture, and you tell them what to do in their execute() method.

A BusinessDelegate class just exposes the Service API, and will be instanciated each time a Command needs to talk to the server. It gets the right AbstractService object through the use of a ServiceLocator that is a super simple non visual MXML which extends Cairngorm's ServiceLocator and contains all the AbstractService (or AbstractInvoker) objects.

You have a Singleton Class, the ModelLocator, that represents your model, and is pretty much just a list of properties, some probably refering to ValueObjects.

Your main view container instanciates the ModelLocator, the FrontController, and a ServiceLocator, if needed. It also binds the ModelLocator properties to the properties of the views contained in this main view container.

To overcome the view-events-to-controller problem, Cairngorm had to re-invent its own observer pattern implementation. Early Cairngorm builds tried to rely on event bubbling, but this technique was discontinued because of its flaws. Today, you have a CairngormEventDispatcher which you have to invoke in order to let it dispatch CairngormEvents that will naturally find their way to the controller. Note that CairngormEvents can now dispatch themselves through the use of a self dispatch() method.

It's very efficient. The problem is, of course, that it's a Cairngorm-only option. If you need a view to dispatch an user interaction event, it either has to dispatch them the Cairngom way, using event.dispatch() (which means that your view is now coupled with Cairngorm), or dispatch the event up the display list, and let the highest view (your main container), be responsible to dispatch them using event.dispatch() (this way, only this main view is Cairngorm-dependent). A third option could be to create a super class for all events in your application, and have it implement the dispatch() method, either by extending CairngormEvent, or using its own magic.

The other problem is that Cairngorm does not offer a elegant way for its controller to communicate back to its views. Various techniques help fixing that issue, but I think that, all in all, Cairngorm does not do a very good job in this area.



PureMVC


PureMVC is a not a Flex specific architecture framework. It's an AS3 framework, written by Cliff Hall.

I've already covered PureMVC vs Cairngorm comparison in a previous post, so I won't enter the details here.

Just like Cairngorm, PureMVC uses a controller / Command technique. Here, the controller is actually a Facade that is responsable for MVC layers instanciations, besides the traditionnal event/Command associations.

The Model is scattered into several Proxy classes, which tend to have a little more responsability than Cairngorm's ModelLocator, since it is considered best practice to use Remote Proxies to communicate with the remote Services.

The views are helped by Mediators which can listen to events and call the views, thus giving the controller a great way to update the views while staying properly decoupled from them.

PureMVC, too, had to implement its own observer mechanism to overcome the Flash/Flex event issue. In fact, it's not even an Event (since PureMVC is independent from flash's framework) : PureMVC uses so-called Notifications. The difference is that, here, Mediators can listen for traditionnal Events dispatched by your views, and then "translate" it into PureMVC specific Notifications.

From my experience, PureMVC does a better job than Cairngorm at architecting your application, but requires more work. I'm so used to using dataBinding to have my views automatically update as a consequence to updating my Model data, that it really seems a step backwards to have to listen for Notifications in my Mediators ad then update my views. Of course, this does not affect all data, but still, it's a significant issue.

Even worst is the fact that, if you want to strongly-type your Notifications parameters (and you probably will, at some point), you'll have to create both Event subclasses (for Views to Mediators communications) and Notifications (for PureMVC internal communications) subclasses. That means a lot of extra work, though justified by the fact that you use a framework independent architecture. This, to me, is quite a big problem, which (as far as I'm concerned) remains unsolved.



Now, which one should I choose ?


Well, you don't necessary have to. I tend to think that a Flex developer/architect should at least have experience with both Cairngorm and PureMVC architectures. And once you know one, getting to know the other is quite trivial.

My point is that using any framework is better that not using a framework at all. Both frameworks have their flaws. But both will help you structure your application, giving you guidelines for its development by providing valuable methodologies. I think the main factor here might be : what do your colleagues use? If they already use a framework on a regular basis, just choose this one.

If this criteria is not relevant, you may have to consider the following:

  • Proper documentation. PureMVC is the winner here. Cairngorm has a pretty poor dedicated website, and almost no documentation. PureMVC has a < a href="http://puremvc.org/component/option,com_wrapper/Itemid,35/">very detailled, updated, diagram based documentation.
  • Strong community support and ressources. Cairngorm is the most discussed, but you can definitely find quality PureMVC resources.
  • Ease of use. I think Cairngorm is easier to understand and use in a Flex application, but you might think otherwise. J2EE developers may also find a more familiar environment there. If you're ready to try the technique discussed ealier, I think it's a real advantage.
  • Debugging. Singletons can mean hell when it's time to debug. PureMVC uses less Singletons than Cairngorm.
  • Requirements. If your application has chances to be even partially ported to another language, well that language may very well be supported by curret or future other PureMVC implementations. In particular, if you also maintain a Flash application (I think many application still have Flash frontends and Flex backends), PureMVC is the way to go.
  • Workflow. There are many Cairngorm Generators but only two (so far, to my knowledge) PureMVC code generators, and a FlashDevelop Template. If your development cycle relies on agile development techniques (such as XP) which requires prototyping often and fast, you'll probably want to use at least one of them.


More Fun !

SilVaFUG Flex Application Frameworks Presentation
http://www.asserttrue.com/articles/2007/10/17/silvafug-application-frame...

Do we need third-party Flex frameworks?
http://groups.google.com/group/flex_india/browse_thread/thread/b501a510d...

10 Tips For Working With Cairngorm
http://www.jessewarden.com/2007/08/10-tips-for-working-with-cairngorm.html

10 Tips For Working With PureMVC
http://www.websector.de/blog/2007/12/25/10-tips-for-working-with-puremvc/

Steven Webster on Why I think you shouldn't use Cairngorm
http://weblogs.macromedia.com/swebster/archives/2006/08/why_i_think_you.cfm

AttachmentSize
NoFramework.jpg46.89 KB
Cairngorm.jpg53.53 KB
PureMVC.jpg57.01 KB

Anonymous on February 25th 2008

Framework A software framework is a re-usable design for a software system (or subsystem). A software framework may include support programs, code libraries, a scripting language, or other software to help develop and glue together the different components of a software project. Various parts of the framework may be exposed through an API. MVC Model-view-controller (MVC) is an architectural pattern, which at the same time is also a Multitier architecture, used in software engineering. In complex computer applications that present a large amount of data to the user, a developer often wishes to separate data (model) and user interface (view) concerns, so that changes to the user interface will not affect data handling, and that the data can be reorganized without changing the user interface. The model-view-controller solves this problem by decoupling data access and business logic from data presentation and user interaction, by introducing an intermediate component: the controller. sources: WIKIPEDIA This issue will continue to cause as much confusion as the Flash3 AS3 debate http://theflashblog.com/?p=328 ... until we clearly define the diffrence between a Frameworks, MVC patterns and a MVC Framework. Based on the above definitions we can clearly see that Flex is a Framework (framework may include support programs, code libraries, a scripting language) and while I have never used Caringorm or Pure MCV my brief looks at both leads me to believe that they are not MVC Frameworks but MVC patterns built to use Flex Framework. Whats more, is that it is debatable that aside from the design patterns that these "MVC" frameworks provide any real measurable benefits to FLEX design / development process when compared to other popular frameworks ROR ruby, CAKE, ZEND, SYMPHONY, KOHANA php check out this kohana post on mvc http://forum.kohanaphp.com/comments.php?DiscussionID=23&page=1#Item_10 , that provide a range of support programs, code libraries, and more importantly data access tools. In fact i believe that they just complicate a design and developemnt combination that beauty was its simplicity....

david_deraedt on February 26th 2008

About your first point, I just can't see what gets you so confused. Let me put it this way : a framework is (mainly), a code library. MVC is an architectural pattern. A pattern, is a common solution to a common (OOP) problem, and is independent from any implementation. Architecture frameworks are libraries of code that try to implement common architecture "recipes" in a particular language, platform, sometimes (this might be what's confusing you) on top of an already existing framework (that is the flex framework, as far as Cairngorm is concerned). Now your second point... well, that's something I hear about everyday, especially from the flash crowd. It's simple : if you can't see the benefits of using patterns, just don't use them. It's completely useless to try to fix a problem you don't have.

Anonymous on February 26th 2008

Great postï¼?thanks for your sharing! i'm using PureMVC now ^_^

Anonymous on February 27th 2008

Very cool post once again, thanks david :) I only kind of slightly disagree when you say "using any framework is better that not using a framework at all", since I like to believe that an experienced developer should be able to properly architect an application on its own, in such a way that it is robust, stable, flexible and maintainable, without the help of a third party. For me, it's not a better approach, it's not worse, if it works, that's just fine. Obviously, putting together a large application requires some structure, and someone doing that will very probably end up implementing some common patterns and following rules, either guided by best practices or by specific objectives, and that could probably be called a framework anyway... But my point is, the solution at the end could be better, could be worse, basically that will depend on the developers skills. Actually, I'm a firm believer that developers should go through the process of architecting applications on their own before diving into third party frameworks. But now, no matter how fantastic, robust, flexible, maintainable a custom solution is, it's true that it will always carry the obvious caveat that it is precisely a custom solution, defining its own rules and terminology, thereby implying that any developer embarking on the project will have to learn and conform to these rules and terminology. And that's precisely imho where architectural frameworks such as Cairngorn come in and add the highest value. From my perspective, and to answer to the previous poster, architectural frameworks are simply about setting up a bunch of rules/conventions, and defining a terminology. Ok, it's a bit more complex in reality, but at the end, it's all about a contract. I would like to recommend reading Steven's article here: http://www.adobe.com/devnet/flex/articles/cairngorm_pt1_02.html to get a better understanding of how such a framework distinguishes itself from both general design patterns and specific application frameworks such as the ones you refer to, or simply Flex. Coming from the Flash development world, having built RIAs pretty much since Flash MX beta days, I've always been immensely frustrated by the fact that there were not two flash developers on earth architecting flash applications in the same way.... Over the time, various people came up with so-called frameworks, but most were bloated and were merely what I would call utilities libraries, with tons of stuff in it, sometimes useful, sometimes not, but most importantly, not operating the essential distinction between architecture and application... Now this, arguably, probably has partially to do with the über versatile nature of flash work, and the extremely fast evolution of the platform, but still, it was frustrating :) The best thing imho with Cairngorn (and PureMVC) is that, for the fist time in the Flash platform history, you have a widely accepted framework, that makes sense, and that is pretty much officially supported by Adobe (this is not the case for PureMVC I think, but there's a strong community behind it) ... It's not necessarily perfect, it's not necessarily appropriate in every situation, but it works AND it's widely used.
  • "It works" means it does the job. It was conceived by experts, driven by best practices and a huge experience and has been succesfully applied in many real-world apps over the years. You may very well have personal preferences that lead you to not like some aspects of one, prefer features of another, but at the end it makes sense and IT WORKS. It doesn't add complexity, at the contrary. Maybe some verbosity, but that comes with the comfort of a very clean, structured and organized framework for your own architecture to implement.
  • "It is widely used" means A. you can scale your project easier if you use it, and B. you can find work easier if you know it :). A: You can add new developers to your project at any time, they will be operational much quicker than with a custom framework, and developers can work on distinct areas of the app much easier. B: As a Flex developer, knowing Framework A means you can board on any project implementing that framework, and believe me, something like Cairngorn is used a lot nowadays.
To conclude, I think an essential reading to add at the bottom of your list for all those considering the use or not of an architectural framework is Steven's post "Why I think you shouldnâ??t use Cairngorm" : http://weblogs.macromedia.com/swebster/archives/2006/08/why_i_think_you.cfm ... Hoping this could shed some additional light on the previous poster's concerns :) my .2â?¬ Jerome. http://www.thisislovely.com

david_deraedt on February 28th 2008

Well thank you for this comment ! ;) I probably wasn't very good at making my point about why "using any framework is better that not using a framework at all". What I really meant is that if you want to implement an MVC architecture in your Flex application, you'd better rely on an established, widely accepted solution such as the two frameworks I talked about, than try to reinvent the wheel. I can't agree more when you say that, in the end, it's all about contracts. The main point is to share a common methodogy, and, as you said, that's a huge step forward from the flash programming habits of the old days. I'm adding Steven Webster's post on "Why you shouldn't use Cairngorm" right now. ;)

Anonymous on March 07th 2008

I'm so used to using dataBinding to have my views automatically update as a consequence to updating my Model data, that it really seems a step backwards to have to listen for Notifications in my Mediators ad then update my views. Of course, this does not affect all data, but still, it's a significant issue. Even worst is the fact that, if you want to strongly-type your Notifications parameters (and you probably will, at some point), you'll have to create both Event subclasses (for Views to Mediators communications) and Notifications (for PureMVC internal communications) subclasses. That means a lot of extra work, though justified by the fact that you use a framework independent architecture. This, to me, is quite a big problem, which (as far as I'm concerned) remains unsolved. This was a mystery to me as well but Cliff Halls response to your earlier post cleared it up for me: However, you don't have to do a lot of work to get updates from the Model to the view. For instance if a Proxy has as its Data Object an ArrayCollection, you can expose that as a public variable, use a Mediator to set a reference to it as the dataProvider of a View Component, and Flex will cause any View Components with a reference to the ArrayCollection to be updated when items are added removed or changed inside it. The same is true of XMLListCollections. Maybe you missed it ;) Cheers, Derek Basch

david_deraedt on March 08th 2008

Hi Derek, This is what I meant when I said "this does not affect all data". But remember that there are many cases when you can't rely on this. Say you have this "currentBook" property in your Model that designate the book that is currently selected in your application. After calling a remote service method such as "createBook()", you now want to designates this created book object returned from the server as the current book. Here, your "proxy.currentBook = createdBook ; " statement will only affect the proxy reference. This is a complex type, but the same is true for primitive types. Each time you actually set a proxy property's value (i.e. each time you use the = operator), you'll have to update the references in the views by yourself. IList objects are a bit special since they use databinding internally, so rather than overwriting them, you can just set their source property, which will trigger databinding. I doubt that your Value Objects all do implement this kind of mechanism. Again, this is expected as PureMVC is not supposed to implement dataBinding since this mechanism is Flex specific, and PureMVC is not. [Edit:fixed some typos]

Anonymous on March 29th 2008

Here, your "proxy.currentBook = createdBook ; " statement will only affect the proxy reference. This is a complex type, but the same is true for primitive types. Each time you actually set a proxy property's value (i.e. each time you use the = operator), you'll have to update the references in the views by yourself. I had to read your reply a bunch of times and consult the livedocs, but I think I get what you are saying now. You are saying that data binding can certainly be used, but it will prevent your code from being platform agnostic and isn't a "true" PureMVC idiom. To be agnostic, a view component should update itself in response to a notification from a proxy. Hence the overhead of a proxy event handler and the notifcation. Derek Basch

Anonymous (not verified) on April 08th 2010

There are MVC frameworks available for flex applications but they are not suitable for designing flex libraries/components.

The problem with the existing frameworks is that the end user of the flex component (application developer) HAS to use the same framework as component.

Is there a way of achieving no dependency on framework for application developer while designing flex component ?

k (not verified) on November 15th 2010

Hi, the link to Joe Berkovitz's An architectural blueprint for Flex applications is broken... Please advise new working link.

Thank you.