AS3 Design Patterns, " />

FlashPlatformist
Articles, Information, News, & Tutorials for Adobe Flash Platform Developers and Architects

Micro-architectures for Flex Enterprise Development

1

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:

  1. They provide a starting point for the architecture of a software program
  2. They establish a set of standards to be followed during development
  3. 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:


Posted by Dan Orlando on March 31st, 2009 :: Filed under Enterprise Flex
Tags :: ,

The “Widget-based Programming Model” for Flex Enterprise Applications

4

I came across this article on O’Reilly’s InsideRIA site by Moxie Zheng and was surprised to find some similarities between the architecture the author describes and the architecture that I am seeking to create. The good stuff begins under the subtitle about halfway down, labeled “The Architecture”, where Moxie Zheng discusses his use of an Event Bus the same way as I have implemented it into my own architecture.

One thing I wanted to point out, and my reason for mentioning it here, is that below that he describes what he refers to as “The Widget Programming Model”, something I have not come across before. When it comes to enterprise Flex apps, we’re usually dealing with multiple user levels. In other words, the interface must look different based on the conditions under which the user is accessing the application. These conditions are often set by an external database server that handles user management, in which user types and their respective permissions may be set in a specific table. Then each user is assigned a user type, or in some cases, multiple user types. Therefore, the client side AIR or Flex application must construct itself “on the fly” so to speak, based on the group of configuration settings that it is handed from the server side. I like this widget-based programming model because it takes custom component development to an even more loosely coupled level, making it virtually impossible for the developer to creat interdependencies within an application due to the nature under which that particular widget must be programmed. It’s loose-coupling at it’s finest.

These “widgets” are compiled as separate swf “mini-applications” if you will, encapsulating and isolating code that handles a specific way of viewing data on the server. As I wrap my brain around the possibilities with this design pattern, I can’t help but think that for applications that are powered by specialized services, a “widget registry” could in fact be formed on the network (talking about AIR applications only now). Therefore, if a user was installing the application based on a certain set of credentials, a call to the network registry would return a set of “widgets” that should be installed along with the main application, thus defining how that particular user views the application interface. This concept could easily apply to the branding of an application based on the web site it was downloaded from, as a simple example.

Possibly Related Posts:


Posted by Dan Orlando on February 2nd, 2009 :: Filed under Enterprise Flex, Tools & Innovation
Tags :: , ,

New Enterprise Flex Development Model

2

This posting is in response to the comment left HERE, which I felt necessitated its own separate post and discussion. Before I start, I must first at least suggest that some research be conducted on Cairngorm, PureMVC, and Fireclay and allow yourself to draw your own conclusions with regard to how they fit into the bigger picture of your enterprise Flex or AIR project.

The first question that Jeff asks in his comment is if I can post a screenshot of a Flex directory structure of an enterprise application. My first thought was that I would make Jeff’s head spin if I did that due to the fact that every enterprise application I’ve worked on has had its own unique set of requirements, and differentiating the parts that could be considered as “standards-based” from those parts that were specific to the application (like a package titled “http” for RESTful services, for example) would not be of any assistance and would leave Jeff (and many others) right back where he started.

So instead, I drafted a diagram (figure 1) that so far seems like it could potentially be the bigger, better, faster, stronger framework for enterprise Flex development. Note that in order to address Jeff’s specific request, I made the diagram to be a sort of hybrid between a directory structure and a design pattern. This is the 50,000-foot view of the new architectural framework that I’m working on. Each rectangle represents a package or directory. Additionally, each layer is in fact it’s own library, with the exception of the Application Layer, which serves as the gateway to the application, and thus it is constructed as a standard Flex project and holds the primary MXML application file.

New Enterprise Flex Application Architecture

New Enterprise Flex Application Architecture

Notice that the different layers are completely unaware of each other. In fact, it is impossible, because if you attempt to add one of the libraries as a reference in the properties of another library, Flex Builder should throw a bunch of random “unknown errors” at you. This is because you have a cyclical redundancy in the build of the Application layer project (note that I am also addressing one of Jeff’s other points, which was to elaborate on the concept of separation of layers in the form of libraries).

In the diagram above, the application layer (which is the ONLY layer created as a Flex or AIR project, not a library project) holds references to the Business Layer, the Component Layer, and the Behavior Layer, which are all libraries and compile as separate swcs. During development however, I suggest you do not add the swcs to the libs folder of the Application Layer project, but rather add them as project references. Then, each time you build, you will notice that Flex Builder automatically recompiles each swc and adds them to the libs folder of your Application Layer project, as long as you have specified the libs folder in the “libraries” panel of the project properties. If you don’t do it this way, you will likely end up with “stale data”, meaning you’ve got an old swc from a previous build of one of your libraries, but the code in that library has been changed.

I must mention that the diagram above is merely a prototype, and has unfortunately not yet been put into practice. Therefore, I am open to feedback on it because, having been dissapointed in the past by Cairngorm and PureMVC, this is what I will be using for my next 2 enterprise level Flex development projects. At the same time however, this is only my first draft. The reason I drafted a diagram of a structure that has not yet been used in a real environment is for the simple fact that I would be doing Jeff – and everyone else that reads this – a disservice by showing you a diagram that is based on a past enterprise level project. This is because with each project, there were architectural decisions made that led to problems later. This is pretty typical when a new language is brought into the enterprise development space, and is to be expected.

The bottom line is that Flex and AIR are still very immature, and those of us who are using these technologies for enterprise development are still learning from our mistakes. Ultimately, we do our best and implement the design patterns we know, often from J2EE patterns since it bares the strongest resemblance to the Flex architecture. However, Flex (and AIR, and AS3 too for that matter) are unique in that they are event-driven. Therefore, a somewhat unique approach must still be taken to an enterprise Flex application that cater to it’s differences. This is why Cairngorm has a breaking point. Once an application becomes massive in size, a Cairngorm-based app turns into spaghetti-code and it becomes nearly impossible to track down events, event handlers, request-response handlers, etc.

Some Important Points

There are a few things I should point out about this initial draft shown above. First, it may not be immediately apparent, but it is in fact based on the MVC (model-view-controller) design pattern. The reason it is hard to tell at first glance is because we’ve got quite a few additional micro-patterns in here. For example, the “event bus” is based on the publish-subscribe design pattern, and I attribute Shashank Tiwari and his work on Fireclay for this idea. Shashank is developing Fireclay as an alternative to Cairngorm and PureMVC for many reasons, some of which I previously stated in regard to Cairngorm. The difference however, is that in the “bindingDictionaries” package – which is probably the most important to make note of in the application layer – is where the mapping of events to their respective handlers occur. This partially breaks away from how the publish-subscribe pattern is being used in Fireclay.

The relational size of the Business Layer/library in the diagram does not do justice for how large the business library will likely get in an enterprise Flex application. There is a lot of abstractions that must be made here and a significant amount of internal processing within this library. One of these abstractions I should point out is that the “model” package would contain a package within it called “vo” or “valueObjects”, which would basically hold references to all of our data as it is captured from the server.

Ultimately, there is a lot going on here and again, this is an over-simplified, high-level overview that encompasses my initial ideas for the architectural design pattern that I am working on developing right now. The important thing about it is that it resolves the many problems that I have seen come up in enterprise Flex development, whether it was a custom architecture being used or Cairngorm, or PureMVC, the problems that arise are consistent.  That is not to say however, that this is an end-all, be-all solution by any means….in fact, it is still just a baby.  However, I will soon find out where the weak points are as I continue to draw out additional diagrams to accompany this first iteration in my efforts of constructing a solid and robust architectural “best practices” standard for Flex enterprise development…well, at least for my own projects:)

Overall, I think the community is in great need of something that supercedes what is currently out there considering Flex and AIR are being used on such a grand scale all of a sudden for enterprise RIA development. I’m not sure if this is the start of something that will fulfill this need for the community, but at the very least it will give me what I need to make my future enterprise Flex projects successful.

There is one last point that Jeff makes in his comment, as follows:

“I’m struggling with the separation/inclusion architecture of these apps because most of them will have interdependencies – security, model, commands, etc.”

The answer here is to simply remove these interdependencies.  If this seems like a ridiculous and nearly impossible solution, then I might suggest that this project will be a nightmare for you until you decide on an architectural solution for this project and just accept the fact that you are going to have to hack away at the code in order to remove the interdependencies. In some cases however, interdependencies are ok. The simple rule with the solution that I have diagrammed above is that if the class doesn’t fit into any one of the 3 libraries, then it belongs in the Application Layer.

I hope this helps.

Possibly Related Posts:


Posted by Dan Orlando on January 26th, 2009 :: Filed under Enterprise Flex
Tags :: , ,

MXML vs. Actionscript

9

I had an interesting conversation this morning with a colleague, who is also a Flex/Actionscript developer, about how we end up using very little MXML when building enterprise level RIA applications. That’s not to say that we don’t leverage the classes that are encapsulated inside of the flex framework, but there is no question that 90% of our code is written in Actionscript. The other 10% are simple MXML files that have no purpose other than to instantiate our Actionscript components on the stage. I think as the Flex developer grows, evolution has it that he or she would move toward the use of Actionscript more than MXML.

A comment I made during this converstaion was that Flex/MXML was great for building little RIA “widgets” that use the built in flex components, which can all be skinned to your heart’s desire. However, it is definitely not well-suited for enterprise level RIA applications because there is too much flexibility (pardon the pun), where we often see programmers literally taking a framework (flex) and language (actionscript 3) that essentially forces you into some form of an object-oriented design, then flipping it on its back to where we see these mxml files that are reminiscent of procedural programming, complete with plenty of inline Actionscript and random switches from mxml to straight Actionscript and back again. This tends to be mostly due to a lack of knowledge on using events and multiple design patterns in a larger application, which takes a while to pick up.

Don’t get me wrong, Flex Builder is definitely the tool of choice for coding RIA applications, but I think the general rule of thumb is that any application that is more than just a “widget”, is going to end up about 80% – 90% Actionscript files and 10% – 20% MXML files. That’s a good way to tell right off the bat if an application is using abstraction and encapsulation of the client-side business logic and behavior versus strictly display. I’ll get more into layering applications in a later blog. For now, here are a few books worth taking a look at if you’re a flex developer on a journey toward learning how to build large-scale RIA apps. All books I recommend are from my personal collection, and I never recommend a book that I haven’t read in its entirety. In other words, I’m not trying to make some cash off an Amazon affiliate program here.

There aren’t too many out there yet on more advanced subjects in Actionscript 3.0, but these 3 will surely help you take it to the next level. Note that the first one I am listing, I attribute some of my most valuable learning to this book and I strongly recommend it to any Actionscript developer aspiring to be an expert at their trade:

AdvancED Flex Application Development; Building Rich Media X
Authors: R Blank, Hasan Otuome, Omar Gonzalez, Chris Charlton
Publisher: Friends of ED
Amazon Link

Actionscript 3.0 Design Patterns
Authors: William Sanders, Chandima Cumaranatunge
Publisher: O’Reilly Media
Amazon Link

Object-Oriented ActionScript 3.0
Authors: Peter Elst, Sas Jacobs, Todd Yard
Publisher: Friends of ED
Amazon Link

Possibly Related Posts:


Posted by Dan Orlando on September 29th, 2008 :: Filed under General
Tags :: , , , , , , , ,