Frameworks – particularly micro AS3 frameworks for Flex seem to be in vogue, but why? What do they offer? Other than adding what looks like making your apps more complex.
If your a Lotus Notes / Domino developer I am sure you have come across the classic tactical application which has grown over time to be a business critical application, you know the one which has had multiple developers over time (who have now left) and of course there is no documentation.
One of the advantages of Lotus Notes is its quick to develop and there are multiple ways to do the same thing – particularly Domino apps.
One of the disadvantages of Lotus Notes is there are multiple ways to do the same thing (you see what I did there 
This leads to an unholy mess of an application – you have code everywhere, you have business logic in hide when’s, you have computed text creating fields on the fly, multiple script libraries with 40 functional routines etc. This ultimately leads to several things happening:
- Bugs and errors go up - but hey doesn’t matter its quick to fix right – maybe before IT compliance rears its head?
- Support and lights on budgets get consumed by these Notes apps, but they were quick and cheap to develop right?
- Adding new functionality suddenly takes a lot longer than you would expect – mainly because you have no idea what the impact will be and you have to find out how it all fits in – assuming you didn’t build the complete app. Ever added a new lookup view to an application because it was easier to do rather than workout the impact of modifying an existing lookup view.
Of course the IDE doesn’t help – the Domino Designer is really staring to show its age when compared to other IDEs. To be fair it has to manage a lot of different design elements as well as 2 clients.
Adobe Flex apps could suffer from similar problems if you followed the same route but this is where a framework comes into its own + some other bits like Unit Testing and Continuous Integration.
Frameworks provide a structure to your applications – i.e. they help to define a best practice application architecture, which ultimately means as a developer you know where your various bits of code should be placed and if you were joining a team or working on existing application you would already know how its structured. Not only do frameworks help with structure they also are designed to make it easier to unit test by isolating key functionality, which also makes it much easier to add new functionality as well as much better reuse.
There are several frameworks available (list taken from http://corlan.org/flex-frameworks/):
- Cairngorm (Adobe Open Source) – MVC framework
- PureMVC (Open Source) – MVC framework
- Mate (Open Source) – Mate is a tag-based, event-driven Flex framework
- Swiz (Open Source) – Metadata-based Dependency Injection framework
- Spring ActionScript (Open Source) – Dependency Injection framework part of SpringSource
- Parsley (Open Source) – IOC Container (Configuration and Dependency Injection), MVC, and localization
- Robotlegs – automated metadata based dependency injection micro-architecture (framework) with a light footprint and limited scope
After looking at several I have decided for now to settle on Robotlegs.
Robotlegs is an IoC/DI container that is modeled on the PureMVC application structure. It is designed to be MVCS, model-view-controller-service, providing metadata dependency injection across these layers.
Ok so what does that mean in English Basically it means that the framework breaks your code elements in Flex down into:
Context – This is where the mapping between the various framework elements happen, its also acts as an event bus. There needs to be at least one context but there can be more.
Mediators – mapped to your views. Mediators are the middle men (or women) between your views and the framework. They pass along view events to the framework and access view methods and properties on behalf of the framework.
Views – your visual components, datagrids, lists etc. The idea here is the visual components have no dependencies on your application. Instead they use mediators to pass information via events out to the framework.
Commands – This is where the business logic lives. These are short lived objects.
Models – These objects do the work on the data. They raise events once the work has been done. NB Value Objects (VO) are associated with the model and provide strong data typing.
Services – This part of the framework communicates to external services (XML, SOAP, RemoteObject etc) and raises events when work has been done.
Communication is done between the framework and the application by using standard flash events.
Heres a great diagram which shows how the bits talk to each other (links to Robotlegs site)
Resources
As part of our preparation for polishing our Adobe Flex skills Mark Myers has suggested a Blog Tag – where we set each other an Adobe Flex technical challenge in which we have 2 weeks to write a blog explaining how to solve it.
