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
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 FlexTags ::
design patterns,
enterprise,
Flex
