DOWNLOAD SLIDES

More than 3 years ago I wrote the following series of articles here:

Introduction to Flex Application’s Architecture - Part 1 - Cairngorm
Introduction to Flex Application’s Architecture - Part 2 - PureMVC
Introduction to Flex Application’s Architecture - Part 3 - The Gugga Approach

Even though this series still attracts a lot of interest, these posts are terribly outdated. A lot had happened in the last 3 years. The Flex framework changed a lot, the application frameworks have matured and my personal understandings have evolved through experience.

The original series has been written in time when the most popular frameworks were Cairngorm and PureMVC. Mate and Swiz we’re there but yet to be adopted and mature. The focus of my writings was to point out the deficiencies of these frameworks. It was a critique of the way these frameworks were implemented, but not a critique on the general approach. As you will see the present frameworks are using the same MVC (Model-View-Controller) pattern, but refined and matured through evolution and application in big complex real-life projects. The power of Flex is now utilized on a completely different level. While the old frameworks were good at imitating Java or technology-agnostic solutions, the modern versions have embraced a more natural to Flex approach.

In the old series I’ve made an attempt to demonstrate you such approach without using any of the frameworks. But in this new introduction to Flex application’s architecture I’ll try something different. No matter what you decide to use - framework or no framework at all, you need to be familiarized with the common set of problems all Flex applications have and which all modern frameworks are trying to address.

My slides and structure of presentation has been inspired from the Richard Lord’s outstanding presentation - Application Frameworks – The Good, The Bad, and The Ugly

Reader’s Prerequisites

The content in this article requires a certain understanding of the following design patterns:

MVC
Front Controller
Command
Observer
Inversion of Control

If you’re not familiar with these patterns please take your time to read through them and make an attempt to understand them. Otherwise everything underneath would appear too abstract and disconnected to you.

Introduction

These days you have a great variety of good frameworks to choose from - Mate, Swiz, Parsley, Robotlegs, etc. You and your team can easily get lost in disputing which one to choose. This article main goals are:

● to reduce the discussion to a set of common problems all frameworks are trying to address in some way
● to describe each of these problems and to present you the various options for solutions
● to introduce some best practices which often take years and many projects for a team to figure out
● to outline a general and practical approach when starting a project

The Common Problems

All modern Flex frameworks are trying to address the following set of problems:

● dependencies management
● events handling
● presentation patterns

Dependencies Management

Components rarely run on their own in full and complete independence. Most of the components depend on other instances of components. You need to take care of creating all needed instances and then pass the references to these components to all other components which collaborate with them. To address these problems the following patterns had emerged - Factory, Singleton and Inversion of Control.

In the slides I outline the following approaches:

● global singleton
● global registry
● manual declarative dependency management with MXML and IoC
● IoC-container

Without going into further details my recommendations would be to start with a manual declarative dependency management with MXML and IoC - while the project is still small this would allow you to start without the need to integrate a whole application framework. Also, while doing the whole dependency management by hand you’ll get some sense on the nature of this task and it would help you understand deeper the whole Inversion of Control-principle. As your project grow bigger you’ll realize that you need a more streamlined and unified approach towards dependency management. When you get there I would recommend you to use a framework that has built-in IoC-container - Swiz, Robotlegs and especially Parsley (this is my favourite). The modern trend is to express dependencies through the use of metadata tags, such as [Inject] or [Autowire]. I recommend you using these when you can.

Events Handling

When there’s graphical user interface there’s also events and handling of events. Events allow to decouple the UI from the controller’s logic. When it comes to dealing with events you need to answer the following questions:

What kind of events should I dispatch?

A rule of thumb is to break the functionality of your application into user gestures. A gesture is a unit of interaction with which the user expresses an intent to perform a functionality (e.g. click the ‘Delete’-button to delete an item, or it could be drag the item to the trash bin). When you break it into gestures, you can create a custom event that signifies the taken gesture. It’s not a good idea to use low-level events, such as MouseEvent.CLICK. Try to use the so called application-specific events - if it’s a click on the ‘Delete’-button, then create a ‘DeleteItem’-event. In such way the application specific event is decoupled from the current interaction that is chosen for the job - ‘DeleteItem’ is abstract enough to be dispatched in either of the cases - click a ‘Delete’-button or drag-drop the item to the trash bin. Sometimes in order to translate a low-level event into an meaningful application-specific event you need to use some form of the Mediator-pattern.

What dispatches these events?

The frameworks usually use the following options:

● using a central dispatcher
● using the display list

My personal recommendation is to use the display list when dispatching events. This would allow in addition to the Observer implementation to add Chain of Responsibility-capabilities.

How to subscribe to the events of interest?

The frameworks provide you again with a lot of choice - the usual discussion here is about pros. and cons. on using Commands or Controllers. While Commands seem pretty straight-forward, I would prefer using Controllers. With controllers I can avoid a lot of duplicating code - mostly the part where you define your dependencies. If a set of commands share the same dependencies and perform logically-close operations I would recommend using a controller annotated with [EventHandler]-metadata tags.

A strong reason to stick with Commands is when you want to support undo/redo functionality - in such cases it is super convenient to store the whole instance of the Command and repeat it if needed. The Command itself could serve the purposes of a Memento pattern.

Presentation Patterns

When it comes to implementing views and view logic, and when it comes to composing views out of other components, Flex offer you a whole spectrum of choices and options - we would refer to this spectrum as presentation patters. Different frameworks are in favor of different presentation patterns.

Code Behind

Historically, this is probably the oldest technique. In short the MXML uses an ActionScript-class as a base tag. Your logic goes in the AS, while the layout declaration is in the MXML. The greatest disadvantage of this approach is that you stick to a base class.

Presentation Model

In this case you don’t need a base class. You compose your component out of a MXML with view and a presentation model component placed in the declarations. The disadvantage of this approach is that you’ll end up with some AS code in the MXML tags. For the purists which strive to keep the MXML absolutely declarative with 0-lines of AS code the following approach has been developed.

Supervising Controller & Passive View

In this approach the view is absolutely passive. The Supervising Controller expects someone to inject the view that needs supervision. I’m a great fan of this approach. The Spark-component model is basically the best example of this approach - the Skin is the passive view in that case and the skinnable component is the supervising controller (check out the sample given in the presentation).

Outlining the Recipe (on how to build a Flex app)

Recipes are good for novices. The following is a very rough outline in 6 basic steps:
1. Always start with the views - complete the views and components you need.
2. Then figure out all application-specific events you need.
3. Dispatch these events.
4. Handle these events in the Controllers.
5. If you need to do any kind of remoting, I suggest you to use a mockup instead of a real server-side invocation.
6. Last, integrate with the back-end services.

Let me know if want me to go into further detail about any of the information in this post!

This post is tagged architecture, flex, frameworks, introduction, parsley, robotlegs, swiz