In the past, I have reviewed a number of the popular frameworks commonly used with Adobe Flex (Flight, Clear Toolkit, Cairngorm, PureMVC, Mate, and Swiz). At Gorilla Logic, we love to debate the merits of each of these frameworks and the MVC pattern in general. As an enterprise software development shop, we love architectural things and enjoy being as geeky as possible. Yet, we continue to be a bit confused with the industry’s over infatuation with MVC and frameworks that exist simply to enforce this pattern (or similar patterns). So, I started down the path of contemplating what would make up the perfect Flex framework…
Over the last decade, most web frameworks in enterprise development seem to just focus on the architectural piece of the puzzle, which actually provides the least value to those tasked with building real applications. Look at the vast majority of Java frameworks that do not even attempt to provide a built-in set of components. Also, in the Flex ecosystem, virtually all the major third party Flex frameworks seem to exist with the primary purpose of enforcing / enabling the MVC pattern, with the notable exception of the Clear Toolkit, which provides an interesting set of enterprise features.
Flex brought on a revolution because it exists first and foremost to make developers highly productive in building cool applications. Thus, Flex is a complete platform, and is often the only framework needed for building real applications. It provides the pieces for building within the MVC architecture and a full set of components that meet many of the requirements found in enterprise applications. When looking at any portion of application development, engineers should only be bringing in tools that specifically satisfy the stakeholder’s functional and non-functional requirements, or address risks specifically outlined for the project. With the strength of the Flex platform, one should not start with the assumption that they need to add in third party frameworks.
That said, Flex does have weaknesses and can be improved upon or extended in interesting and useful ways. Also, it can be helpful to have infrastructure that supports developers in properly separating concerns within the application code. Frankly, if the costs of adopting a third party framework to get this infrastructure is low, then there is no reason to fight against bringing in an outside solution. Let’s look at a few of the Flex frameworks to see how they measure up in this respect:
Cairngorm: The cost of adoption and long-term ownership is too high, with the high volume of code required for implementing even the most trivial feature, for one to seriously consider this as an option. The leverage just is not here.
Mate: Mate addresses separation of concerns by providing developers a global event bus for handling events. This approach fits well with the real way Flex applications are built. Although, I tend to believe that not all events are global and likely do not all need to be externalized, but this is certainly an important piece of the puzzle. With a reasonable technical approach to managing events, the overall cost of adopting Mate is low.
Swiz: Swiz is similar to Mate in that it has a limited surface area for developers to learn. Its primary mechanism for separating things out is the use of dependency injection. It is fairly elegant in its syntax and easy to use.
While two of the three outlined above are low cost to adopt, they are also limited in the number of problems they solve for a Flex developer. That’s really what this post is about – working through where the leverage is/should/could/would be in the Perfect Flex Framework. In part two, I make an initial attempt at providing my requirements for the perfect third-party framework.
