막강 잔지식 집합소 ver.1 :: Flex Architecture Fundamentals Part 4 : Architecture Frameworks

Flex Architecture Fundamentals Part 4 : Architecture Frameworks

Study/Flex 2008/06/15 13:21 |

Mon, 02/25/2008 - 16:04 — david_deraedt

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.