Bony (a colleague of mine) and I were invited to make the closing lecture for the Flex course in Sofia University. They wanted us to make 2 consequent lectures that will summarize the whole course, but also leave the students the door wide open for new stuff to learn and experiment with. This led me to the decision to talk about architecture and instead of doing a thorough lecture on such a complex topic I wanted it to feel more like an introduction. I was afraid that a simple introduction will eventually leave the audience with empty hands, so I included some very typical Flex design patterns, related to Data Binding and Inversion of Control, but also wanted to share couple of approaches to Rich Internet Application development - Front to Back development and Feature Driven Development.
I usually prefer to use very short slides with just enough information on them, but I’m aware that this kind of slides are only effective during the presentation and completely useless after that. Publishing them is not enough, because they are very short and not very informative. So, I write this post in order to be used as notes accompanying the presentation. Before rushing into the popular Flex application architectural frameworks we need to answer one question.Why architecture is important?
Alan Kay gave a nice sample on importance of architecture in his OOPSLA’97 keynote and I will use it here too. We can build a decent dog house from almost anything - you just need a hammer, nails and some randomly picked wooden boards. Having a plan is not necessary, but even if we need one it is going to be very simple.
Now, let’s expand this thing about the factor of a 100, thus we can get something with the size of a cathedral. Every engineer should know that scaling this thing 100 times, will actually increase its mass 1,000,000 times and its strength only by the factor of a 10,000, which actually means that the new construction is going to be 100 times weaker than the original dog house. Most probably it’s going to collapse under its own weight.
Well, if you want to stick with small creations and simple structures you don’t need an architecture. But if you want to deal with complex and big structures, then you should start getting interested in architecture - literary the designing and building of successful arches. But to build something expanded by the factor of a 100 we need a new concept - a non-obvious, non-linear interaction between simple materials that would give you a non-obvious synergies and a vast multiplication of materials. As complexity starts becoming more and more important architectures are always going to dominate material, which in the context of this topic simply means that architecture is always going to dominate the technology of our interest. That’s why architecture is important!
A word on architectural frameworks
A framework is defined as a set of cooperating classes that make up a reusable design for a specific type of software, but what’s an architectural framework? We can define an architectural framework as a set of cooperating design patterns that make up a reusable micro-architecture for a specific type of applications. Now as you know what an architectural framework is I can start making an overview of the popular Flex architectural frameworks.
Cairngorm
This is the most popular architectural framework for Flex. It is so popular that developers are starting to overexploit it, as it is some kind of a panacea for the design and development of RIAs. Well, if you have no experience at all, most probably you’ll start with Cairngorm, because of its straight forward usage and the fake sense of confidence it gives to beginners.
Generally speaking Cairngorm is an MVC micro-architecture composed from a FrontController which maps application specific events to commands, a ViewLocator which is a dictionary for ViewHelper classes, a ModelLocator which is the main abstract representation of the application state and data, and a ServiceLocator that stores the variety of services an application consumes. Most of the application logic goes in the Commands implementations. The easiest way to define a command is as the actions and logic that should be performed in response to the meaningful user gestures. By meaningful I refer not just to all user gestures, but only these that trigger the execution of the business logic behind the application.
It’s relatively easy to incorporate Front to Back Development when using the Cairngorm micro-architecture. Basically, you start with some View, define all user gestures and corresponding Events and Commands for that View. Because of the rich component set provided with the Flex framework developing a prototype that broadcasts the defined Events is a piece of cake. The next step is to implement the corresponding Commands. Usually the commands are just updating locally the state of the application stored in the ModelLocator or before updating the model the data is processed remotely from a back end service. To implement such commands that require remote processing the Cairngorm team proposes the use of BusinessDelegates which encapsulate the whole request-result logic. You only need to configure the needed BusinessDelegate by providing it with result and fault handlers. Usually these handlers are functions within the Command that uses this BusinessDelegate. By the time you build the prototype, most probably you won’t have an available back end application. If that’s the case, you can use mockup BusinessDelegates, which process the data locally and return fake results. As soon as the back end is ready you can easily switch to remote processing and real data, but instead of waiting for this task to be accomplished you’ll have already evaluated the prototype with the customers and the precious feedback is going to be available much sooner, thus boosting requirements elicitation, customer communication and satisfaction, and drastically improve the overall user experience. Another way to approach Flex application development is Feature Driven Development. First, you need to build the overall application model. Second or in parallel, you need to compile a list of required features. It is useful to map features to user gestures, which in the context of Cairngorm can be mapped to Commands. With Cairngorm it’s easy to streamline the development of Commands - you can easily define concrete steps for implementing every feature - something like, define and dispatch Event from View, create entries in the ModelLocator, implement the needed BusinessDelegate, implement the Command that updates the model and finally define a mapping in the FrontController between the Event and the Command. This type of streamlining can be useful within big projects with 10,000 features and a staff of 100 not very experienced developers. You start dividing this huge list of features into sets, that can be developed and deployed within short iterations - usually 2 weeks. Well, that’s a Feature Driven Development! Don’t get me wrong Front to Back development and Feature Driven Development are not orthogonal approaches. Combining them is an intelligent decision, but this is a matter of a different discussion.
Some words of warning
By the time, you get to this paragraph, you should have some really nice impressions on Cairngorm. It looks like you can handle almost everything with this so influential framework, but you should be aware of the huge disadvantages, which you’re about to uncover in the middle of the development of your next big Rich Internet Application.
First, the number of Commands can easily grow from 10 to 1,000. By the time you hit the count of 100 you’ll realize that most of the Commands are very similar, just differing in the type of data they process. This huge number of Commands means huge number of classes, which leads to a huge size of the application, not to mention the annoying compilation time. You should start thinking about generalization and new ways to reuse this repetitive logic. Second, as the project grows in complexity it’s model or application state stored in the ModelLocator are going to get very complicated. It’s kind of difficult to decompose this model into something smaller, more granular and not that monolithic. Third, in cases of complicated user interaction the logic for that interaction appears too far from the View. Commands that need to manage and use the Views are utilizing the ViewHelper classes. While this sounds reasonable in the context of this architecture, I see no point in getting through the whole Cairngorm cycle of processing of events to execute some logic that should be rather positioned near the View. Well, it’s just the way how Cairngorm tries to uniformly treat every user gesture.What’s next?
Part 2 of this topic is going to be about the PureMVC architectural framework. In Part 3 I plan to show you a very different approach - an approach more natural to Flex. You don’t need more to get more! So, stay tuned!
Reference
Introduction to Flex Application’s Architecture - the slides of the talk I gave at the Sofia University
Alan Key: The Computer Revolution hasn’t happened yet OOPSLA 97
CairngormDocs.org - a community driven site, devoted on systematizing the documentation and learning resources for the Cairngorm micro-architecture for Adobe Flex.
This post is tagged Adobe Flex, Alan Kay, architecture, Cairngorm, feature driven development, flex, front to back, introduction, methodology
No Comments
Leave a Reply