Layering Code for Large-Scale Flex, Air, and Actionscript 3.0 Applications
With all of the books that I’ve read on Flex and Actionscript 3.0 development, I find it interesting that none of them go into detail about the organizational structure of an enterprise level RIA application built with Flex. Perhaps Flex is still too immature and has not really evolved enough yet to write on such topics. Nonetheless, that is exactly what we are going to discuss in this article. More specifically, we will go into detail on how one might want to structure an RIA application that he or she expects to grow very large in size. In other words, we will pay particular attention to designing an application foundation that is scalable in nature.
In order to cultivate a development environment that caters to ultimate scalability, we must start by separating our code into clearly defined layers. By layering our code, we are able to entertain a high level of abstraction in the logic. Most RIA applications are split into 3 initial layers by nature: the server side logic and database, the client side logic (and database also if we’re working with an AIR app that uses a client-side DB as well), and the medium that is used for client-server communication. Here are two examples that come straight from the two big projects I am currently part of:
Project 1
Client-side: AIR desktop app & SQLlite
Server-side: Java/Jboss with MySql Enterprise
Client-server communication: Custom Java REST service and JVM (Java Messaging Service)
Project 2
Client-side: Flex application (runs through web browser)
Server-side: PHP (custom built PHP framework) & MySql
Client-server communication: AMFPHP/Remote Object, Flash Media Server
As you can see, this kind of layering is inherent to any RIA application by nature, but our focus is splitting the client-side logic further into an additional set of layers. It is important to note that this is generally what you want to be considering before starting any development work on the project. Of course, that’s easier said than done, which is why a large number of applications in any language are overhauled once or even twice a year because there just wasn’t enough scalability built into the previous version. Nonetheless, using this article as a resource when you first begin the design of a what could become a fairly large application will definitely put you a step ahead. The same also applies to smaller applications that require a lot of custom functionality (i.e. using the built-in flex components are not really an option).
Layer 1: The Business Layer
The business layer is the core of the client side application and is completely encapsulated in such a way that nothing is ever brough up to the user interface level. In other words, it is completely hidden and works entirely behind the scenes. It’s job is to feverishly work to make sure that the user interface always has the data that it needs, when it needs it. The business layer should include: the data model, a set of value object classes, an event model, its own internal services layer for communication with the client side database (if applicable) and the server, and a primary controller class for the user interface to hook into. We make this layer its own flex library project because it has no dependency on display whatsoever.
Layer 2: Custom Component and Behavior Layer
This is the “middleman” of our user interface, and is often composed of classes built with the factory design pattern. Its job is to listen for events fired from the business layer and instantiate it’s built-in event handlers, which may be to display a popup component, change the application state, or shout out commands to particular components like “do this animation!”, or “move to here and show this data!”…you get the idea. Things you might see in the component and behavior are: custom actionscript components, use of the drawing api, programmatic animation and movement, programmatic skinning, and factory classes that ultimately control all of the behavior of the display components. We create a separate Flex library project for this layer as it is not directly part of the display. Note that we can even place some of our mxml components in this layer and still keep it as a separate library because we can just call those components from the display layer if we wanted to. Whether or not you do this however, largely depends on the size of the application. Otherwise, I suggest keeping all of the mxml in the display layer.
Layer 3: The Display Layer
This is what we can refer to as “the UI layer”, in that it defines our user interface. This is typically where you will find most, if not all of the mxml files. This is our Flex or Air application project, and it includes the business layer and component/behavior layer libraries by referencing them accordingly (see below, under “Setting it Up”). Very little actionscript should be needed in these mxml files, as they are like “dummy” files that simply define the layouts of the different states of our application. They are more like “wireframes” than anything, as our actual design should be defined either in CSS stylesheets or on layer 2 for programmatic skins. My suggestion is also to do some research on the flex component plugins for Illustrator, Flash, Photoshop, and Fireworks if you haven’t already. Using these nifty little tools that Adobe created for us, we can let the design application compile a single swf for us after you’re done creating your skin, with all of the images inside of that single swf file, then import it into Flex Builder by going to File->import->skin artwork and selecting the skins you want to import. This will save you a considerable amount of time, and allows you to take the abstraction of your application one step further by separating the design from the layout on the display layer.
Setting it Up
When you setup the layer 1 and 2 projects, when you go to File – new flex project, make sure that “flex library project” is selected in the configuration window that pops up. When you setup the Display Layer project (I would suggest choosing a different name than “Display Layer” by the way, but that’s up to you), make sure that Flex Application is selected. Then go to the project properties for the Display Layer project in flex builder, click “Flex Library Build Path”, select the Library Path tab, and click “Add Project” (as opposed to add swc) and add the layer one and two libraries that way. I suggest adding swc’s or adding a swc folder (which you then place your swc libraries into, usually called “lib”) only for components or libraries that are complete in their entirety and you will not be making changes to. The “Crypto” or “Corelib” swc libraries offered by adobe for data serialization and data encryption are examples of when you would add a swc or swc library folder (and place your swcs inside of it, which is the best way to go). That is not to say that you can’t use the swc’s for your libraries, as whenever the swc is recompiled, it will automatically be updated in the main application project, but Flex still has some bugs with regard to this functionality, so my recommendation would be to steer clear of it for now unless the library does not need to be modified.
Final Thoughts
It is worth noting that this structural pattern caters very nicely to multiple-developer environments, and each layer could even be split further into additional libraries, where each developer has their own library project, and because so little development is really happening on the display layer (it should only account for maybe 5 to 10% of the application at most), developers rarely run into each other because they are mostly working on their own library project. Each developer can additionally test their code by running the main application mxml file in the Display Layer application locally, which has all of the libraries referenced. Source control is obviously critical for this to work though.
Hopefully this article sparked some new ideas, and feel free to leave a comment describing how you might alter this structure with your own ideas and design patterns.
Happy Flexing!
Possibly Related Posts:
- Second Generation Micro-architectures, Part 1: The Swiz Framework
- Flash Camp Phoenix a Huge Success
- Using the Zend Framework to take some wind out of AIR
- Building Custom Components with Flex 4
- Understanding the Flex 4 Spark Component Architecture and how to Build Custom Components with the Flex 4 SDK
Posted by Dan Orlando on September 29th, 2008 :: Filed under Enterprise Flex, Tutorials
Tags :: AIR, code separation, Flex, library project, OOP, patterns, RIA application, scalability
