Cairngorm – Flex Application Framework (My Initial Reactions)
jonr originally posted this on Jon Rose's Blog.
I have been looking at the Cairngorm Flex Application Framework. Cairngorm is a MVC framework implemented in ActionScript 3.0 to support development in Flex.
As a Java developer, I have quite a bit of exposure to the MVC pattern, and I definitely want to have a healthy Separation of Concerns (SoC) within the Flex applications I am building. However, I am a bit surprised that I have not found much push back online from the Flex community on introducing the high level of abstraction that comes with the Cairngorm framework.
I absolutely believe in having some consistent structure for separating view logic from model logic (and so-on), but it just seems that Cairngorm could be a whole lot flatter. My first pass at writing code with the framework takes me back a few years to when my peers and I where implementing the Session Facade pattern in web applications that where deployed in a single container, and were never going to have more than 10-20 total users. In hindsight, this was obviously totally unnecessary and an inappropriate use of the design pattern. It seems like Cairngorm could be taking us down a similar road here.
Regardless, I have decided to use Cairngorm in my first Flex application (it seems to be the Flex MVC framework with Adobe’s endorsement), as I hate spending a lot of time writing my own plumbing, especially when I am still getting up-to-speed on a language (i.e. Flex). However, my usage of the framework comes with a number of concerns upfront. I thought I would outline my initial reactions and concerns, and see if they still hold up after using Flex and Cairngorm for a while.
The first resource I used to gain an understanding of Cairngorm was their overview diagram of the ‘Cairngorm 2.0 Microarchitecture,’ found at: http://www.cairngormdocs.org/cairngormDiagram/cairngorm2_rpc.swf.
My immediate reaction after viewing the diagram was, ‘Wow! The whole Core J2EE Patterns book duplicated. Really?’ It would appear that the Cairngorm developers owe Deepak Alur, Dan Malks, and John Crupi a big thanks for their contribution of the Core J2EE Patterns. As someone who has used, and at times abused these patterns, I am not completely sold that this is an appropriate place to utilize them (at least not to this extent).
My first question is, why do I need this level of abstraction when there is a natural SoC in the client-server like programming model of Flex? Think back a few years to early web development in Java. With Java I can issue SQL statements directly from a JSP (and many developers did/still do). Most everyone agrees this is bad, thus the Java community responded with countless MVC frameworks to enforce more discipline and give direction to misguided folks who would do things like issuing a SQL statement directly from a JSP.
Flex does NOT offer any API’s for database access, as it is just a client-side presentation framework. If you want to access an SQL database you have to go through a business services layer (e.g. SOAP, Data Services, etc…) that encapsulates the logic for accessing the appropriate data. Thus, you have a natural SoC in Flex that does not exist in pure Java deployments.
My next question, why introduce a Front Controller into an event programming model like Flex? The Front Controller seems to be a perfect fit for Struts, as it was building on Servlet/JSP development where there was little notion of state and no event model. In addition, the entire flow can be controlled in a Flex based application, unlike traditional browser based deployments where a user could potentially jump into an application at any point by simply providing the URL.
Also, in the example applications the Front Controllers do not seem to be doing anything except dispatching custom events. No security checks, no decision points on redirecting the view (as Flex provides View States for this), none of the typical benefits outlined in the pattern.
Moving through the diagram, the Business Delegate makes good sense to me as a way to encapsulate interactions with the server. Although, I am surprised that the logic that ends up in the Commands (in the example applications) isn’t just part of the Business Delegate. I tend to view the delegate as a client that makes the call, does any necessary translation, and returns meaningful data types to the client side application. The delegates in the samples pretty much just provide a handle to the remote services, and the Commands make the call using the Delegate and return the meaningful types to the Flex application.
The Service Locator seems to make good sense, as a way to organize and access the different services needed for a given Flex application. Although, it does not appear to be a true Service Locator, but just a way to encapsulate the client side configuration for accessing the remote services.
I think that the custom events and value objects also make good sense, as they would be apart of any implementation that moves the model and flow logic outside of the mxml components.
Anyhow, after all of my analysis… I do still plan to use Cairngorm for an implementation I am coding in Flex, and then review my initial thoughts outlined in this post. Although I think it is overkill, I do believe it provides me the SoC I am looking for, and is good enough for right now. So, on to writing code!!!
Resources