Version 0.3 of my new Flex enterprise development model got quite an overhaul. For those who are not familiar with the background of this posting, I am on an endeavor to create an alternative to Cairngorm and PureMVC for enterprise Flex/AS3 application architectures; particularly one which caters specifically to the Flex framework and is not based purely on J2EE best practices. A few points worth noting that I have yet to point out with this architecture:

The UIController

The UIController is meant to be a singleton class that provides access to the central event dispatcher (the event bus), as well as the model, which would likely be a getter for a centralized model class in the business library, which then has getters and setters for all the value objects contained in the model package. The UIController would be instantiated by the LifeCycleManager class, which would also have the responsibility of determining the application’s initial state (for example, if credentials are already in the encrypted local store and can be validated, go straight into the app without asking for credentials). The lifecycle manager also waits for a “MODEL_INITIALIZED” type of event, letting it know that any of the necessary client-server communications required prior to display of the initial application state are completed, at which point it instantiates the UIController. The UIController would also contain a command called something like “setBindings”, which would iterate through the bindingDictionaries package and set the bindings accordingly. With regard to this method of setting bindings, I still haven’t figured out how to handle non-instantiated view components with regard to this process yet. My objective here is to somehow centralize all of the bindings so that the developer can see how everything is “mapped” so to speak between view components and the data model. Technically, this is where the controller logic in the MVC pattern lies in this architecture.

Obviously there are some inherent issues that come with this.  My concern is that when an architecture has a substantial use of registries, the design patterns within the architecture become suspect.  However, it seems that it is most logical right now to use internal registries for services, commands, and events (although this may change).

Demarcation of the Business Layer

In the diagram, the demarcation of the business layer is quite clear, as I have now separated the architecture into two primary layers, one for business logic, and one for the actual GUI. For example, client-server communication and the construction of the model in the form of value objects happens within the business layer. Say for example that we have an AIR application that must ask the server if there are any tasks that have been created on the server side for it since the last time it ran. The server responds with a task to remind the user that their subscription is about to expire. That is then stored in the applications local sqllite db, and  the task is sent to a task handler queue to be handled in the background while the application is running.  When its time to handle the task, a notification event is fired, which goes through the event bus and displays the message in the UI.

Alternative Enterprise Flex Architecture - version 0.3

If you have any questions and/or feedback, please do not hesitate to comment. Questions and comments are critical for identifying weaknesses with this architecture.

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
• Micro-architectures for Flex Enterprise Development
• Understanding Flex Communication Protocols

I’ve updated my new proposed architecture for Enterprise level Flex and AIR applications. Although it is still nothing more than a single diagram, I am feeling more confident about it nonetheless. Not surprisingly, this version has inherited additional concepts used by Shashank Tawari and his Fireclay project, specifically the service registry. It seems to make a lot of sense to register all services in one central location, which can be used by the bindingDictionaries to bind classes in the command package as result handlers for services located in the serviceRegistry package. I’ve also incorporated a UIController class. For those that are familiar with J2EE or Cairngorm, this is not to be confused with the concept of the FrontController, as UIController acts more like a traffic cop. In the first iteration, UIController was abstracted in the business layer/logic, providing data model access. Instead, it’s purpose is now to simply be a mediator processes occuring within the user interface. It is also meant to be the single point of access for the event bus between the application layer/gateway and the abstracted functional libraries. You’ll notice the use of the term “library” instead of “layer” as well, in order to minimize confusion.

Proposed Enterprise Flex Architecture - v0.2

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
• Micro-architectures for Flex Enterprise Development
• Understanding Flex Communication Protocols

The Flex documentation on the UIComponent life cycle is rather difficult to understand, and so I came up with what I felt was an easier and more logical way of describing the process. I felt this might be useful for those who are interested in creating custom visual components in Flex that extend the UIComponent class. Creating custom components without having a solid understanding of the functionality that is abstracted within the Flex framework in regard to how it lays out UIComponent objects will likely result in design decisions that are inconsistent with the Flex Framework, which could potentially lead to a frustraing and seemingly uphill battle between the developer and the framework.

The following flow diagram represents the process that is abstracted within the Flex framework when the addChild() command is made to create and make a visual component visible on the stage, or when the properties of the component and/or it’s parent change (like a new data update for example):

Life Cycle of a Flex UIComponent

Note that if that is a little hard to read, you can click on it and it will brink up a pdf version. This is identical to what is said in the Flex documentation, it is just a lot easier to understand for those of us who appreciate visual representations of processes that are comprised of many steps. It is just easier to follow.

You will notice toward the bottom the diamond shape, which represents a decision that has to be made. The thing to understand here, is that additional components may be going through this same process simultaneously, thus affecting the layout properties of each other. An example might be the resizing of the parent window. The invalidation methods in essence, act as a sort of “queue” so to speak, so the actual stage ends up redrawing just once even though a number of things may have changed. The point at which the UIComponent makes the decision on whether or not to re-render is sort of like it is checking itself to make sure that it is ready before becoming visible. If a number of visual properties have been set on it or something else changed again that forced the invalidation methods to be called again on the components, it re-runs the commitProperties(), measure(), layoutChrome(), and updateDisplayList() methods again, and will continue to do so until it knows that it is now ready to be seen, at which point it’s visible property is set to true.

The speed at which this all happens and the overall architectural decisions with regard to how the stage is drawn in a Flex app and the way the visual elements are laid out, is truly quite impressive, and worth studying in further detail if you are interested in learning more about the design patterns used in the Flex framework to make it work the way it does. Although Flex does have its flaws, this is an example of how the framework abstracts a lot of functionality quite elegantly for the developer.

Possibly Related Posts:

• Flash Camp Phoenix a Huge Success
• Building Custom Components with Flex 4
• Understanding the Flex 4 Spark Component Architecture and how to Build Custom Components with the Flex 4 SDK
• Peter deHaan on using Spark controls in Flex Gumbo
• Understanding Flex Communication Protocols

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:

• Second Generation Micro-architectures, Part 1: The Swiz Framework
• Open source clientside RIA frameworks for SaaS
• Using the Zend Framework to take some wind out of AIR
• Traditional Project Management vs. Agile Development with Software as a Service projects
• Data-centric Adobe Flash Builder development with the Zend Framework