Micro-architectures for Flex Enterprise Development
The key to writing solid enterprise Flex applications is to fully understand the overall architecture of Flex as a framework, as well as the various design patterns contained within it. By maintaining consistency between your micro-architecture and the Flex framework’s architecture, the application design and development process is guaranteed to be smooth, effective, and simple.
I must first point out that there exists a significant different between an application framework and a micro-architecture. Flex is an application framework based on ActionScript 3.0, whereas Cairngorm – for example – is a micro-architecture for Flex. Currently, there exist two architectural frameworks for Flex that are in full release; Cairngorm and PureMVC. Micro-architectures are good for three primary things:
- They provide a starting point for the architecture of a software program
- They establish a set of standards to be followed during development
- Standards lead to consistency, which makes the code within enterprise applications easier to maintain and add new features to later
Understanding Flex Architecture
The first thing to know as an enterprise Flex developer is that Flex is based around the Model-View-Controller (MVC) architecture. MVC became popular in 1995, when SmallTalk was the language of choice for a large portion of client side application development.
The second thing to know is that MVC is a global architecture in that it is a model that is meant to represent an entire body of code, whether it is an application or an application framework. In other words, it is a method of organization for a large amount of code. Therefore, expect to find a number of design patterns contained within an application or framework that models MVC architecture, including Flex.
These design patterns depend entirely on the problems that must be solved with the application or framework. It is therefore theoretically possible to have billions of architectural frameworks for a single language, all based on the same MVC structure. However, the problems we encounter in enterprise software development tend to remain relatively constant (although they to evolve and change over time), and therefore it is unlikely that we would ever see that happen (although J2EE does have 72 so far!).
Cairngorm
Cairngorm is a micro-architecture for enterprise Flex applications initially created by a company known as Iteration II, which was bought by Adobe Systems and merged with Adobe Consulting. Since then, Adobe Consulting has made strong efforts at focusing the continued development and maintenance of Cairngorm around that of Flex. It is for this reason that Cairngorm is worth more than just a look when considering a micro-architecture for your enterprise Flex application. Furthermore, if you’ve already commenced development on an enterprise level Flex or AIR application and you’re just reading this now, not to worry. The Cairngorm documentation does an excellent job at explaining in a step by step process how to go about integrating the Cairngorm framework into an already existing enterprise Flex application.
Iteration II was a firm that did much of it’s development in J2EE. As a result, Cairngorm implements a number of design patterns that are most popular in J2EE development. With that in mind, Flex developers that come from an enterprise Java background should be able to get used to Cairngorm fairly quickly and easily. Even if you don’t have an enterprise Java background, Cairngorm is still an easy platform to understand as long as you are familiar with basic object-oriented programming concepts and design patterns.
Some of the more distinguishing factors of Cairngorm include the use of a central event and central event dispatcher, and the use of business delegates. Cairngorm is centered largely on the use of the observer and command design patterns and does a pretty decent job overall with regard to abstraction and encapsulation of code.
The strongest criticism against Cairngorm has been that it implements J2EE design patterns that are “force-fit” into the application architecture. An example of this is the use of business delegates.
PureMVC
The PureMVC micro-architecture focuses on maintaining strict adherence to the MVC architecture. PureMVC actually started as an enterprise architecture for ActionScript 3.0 including Flex, Flash, and AIR. The architects soon realized that their architecture could apply to a number of other languages as well. Since then, versions of PureMVC have been created for C#, ActionScript 2.0, ColdFusion, Haxe, Java, JavaScript, Objective C, PHP, Python, and Ruby.
The most obvious characteristic of PureMVC is that it relies heavily on the Singleton design pattern, in that there exists a Singleton class that holds all references for each of the three MVC layers. Whereas Cairngorm relies on “value objects” for data transfer (also known as DTO’s or Data Transfer Objects in Java), PureMVC uses proxies to manage data objects. Other design patterns used in PureMVC include: Façade, Mediator, and Command.
The biggest argument against PureMVC is the lack of true abstraction and encapsulation due to the fact that pretty much any object or class can access any other object or class. The Singleton design pattern is probably the most controversial of design patterns among architects due to the fact that Singletons and Multitons are not necessarily meant to be used liberally, and should only exist for certain specific instances. It is therefore argued whether or not PureMVC is truly using what is considered to be “best practices” in the world of software architecture and design patterns.
Alternatives to Cairngorm and PureMVC
Comparatively speaking, AS3, Flex, and AIR are in their early stages of evolution, as are most technologies that fall under the RIA classification. For example, JavaEE has over seventy different architectural frameworks available, each of which is focused on solving a specific type of problem. This supports the argument that there is no “one size fits all” solution, which is what both Cairngorm and PureMVC attempt to be. If this were true, there wouldn’t be a new architectural framework released for J2EE practically every month.
Most Flex developers are still coming to grips with the architecture that is contained within the Flex framework, so it has not become common practice yet to propose new architectural frameworks for enterprise Flex applications. It is noteworthy however, to point out one exception, called Fireclay.
Fireclay
Shashank Tiwari, a well-respected software architect and author in the Flex community, is the sole author of the Fireclay framework, which is currently in its infancy. It is however currently available on Google Code, and well worth consideration for your next enterprise Flex application. His most recent book, Advanced Flex 3 (Friends of ED), describes Fireclay in further detail in the first chapter. Other than that, there is little documentation, although the author has promised to provide a fair amount of documentation and explanatory examples in the near future. The code is well commented though, so experienced architects should be able to quickly come to grips with this framework. If you do decide to use Fireclay as a starting point for your next enterprise Flex application, I strongly recommend that you pick up Advanced Flex 3 and use the first chapter to help you understand the underlying concepts that drive the Fireclay framework.
There are several notable differences that make Fireclay stand apart from Cairngorm and PureMVC. Fireclay goes beyond the traditional page-based web architecture constrained and governed by the HTTP protocol and attempts to leverage the benefits of the thick and rich client. To start with, it provides a clear separation of the interaction and business logic from the view and model elements. It accomplishes this by placing the commands and services on the controller layer of the MVC architecture and uses an “event bus” for communications between the model, view and the controller. The “event bus” facilitates the implementation of the event collaboration design pattern and realizes the loose coupling goals of a scalable and modular application.
Additionally, models are separated into two categories, a “local model” and a “proxy model”. This allows for appropriate source binding, caching, paging and lazy loading of data. For large applications, the framework provides registries to catalog commands, services and model elements. This reduces complexity and avoids code clutter and obfuscation. The views are assisted by helpers where required and are updated on model change events. The views read model elements and updates using the traditional observer-observable pattern. This is consistent with the Flex framework, and as previously stated, consistency between the design patterns used in the Flex framework and that of your enterprise application architecture is a primary key to success.
Roll Your Own Architecture
The other alternative option you have is to roll your own architecture. In order to do this however, you should – at a minimum – have a firm understanding of the 23 architectural design patterns as outlined in the book titled Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, Helm, Johnson, Vlissides; Addison-Wesley; 1995). If you do not have this book, then get it…Now.
Additionally, you must have experience working with the Flex framework from an architectural standpoint and understand the design patterns that are used within it so you can maintain consistency with it in your architecture.
Lastly, and most importantly, don’t succumb to the false authority of tools or models. There is no substitute for creativity, intuition, and inventiveness. Keep in mind that the context of the application is critical. There comes a point where architectural rules are counter-productive.
Generally speaking, the time it takes to come up with workable solutions within your architecture depends on how complex the problems are that it is responsible for solving.
Conclusion
It seems quite common these days to mistake such micro-architectures for being a one-size-fits-all set of rules and methodologies that must be blindly adhered to and precisely followed. This type of mentality is counter-productive and stifles creativity. Every application is full of unique problems that require unique solutions, and to think that there is any “one size fits all” solution to enterprise application development projects is just pure ignorance. It is therefore important to use your best judgment based on the situation when choosing how to approach an enterprise level software development project, and Flex applications are no exception.
Possibly Related Posts:
- Second Generation Micro-architectures, Part 1: The Swiz Framework
- Using the Zend Framework to take some wind out of AIR
- Thinking Outside the IDE: Ideas for Flex Architects
- Understanding Flex Communication Protocols
- Enterprise Flex Model – v0.3
Posted by Dan Orlando on March 31st, 2009 :: Filed under Enterprise Flex
Tags :: AS3 Design Patterns, design patterns
