Prerequisite knowledge
Prior experience with Flex or ActionScript development will be helpful in understanding how SourceMate features improve productivity.
Additional required other products
SourceMate 3.0
User level
Required products
Flash Builder (Download trial)
Required products
Flash Builder (Download trial)
Inversion of Control (IOC), also known as Dependency Injection (DI), is a design strategy that has become popular in software development over the last few years, leading many Flex developers to explore frameworks such as Spring ActionScript, Parsley, Flicc, and Swiz.
In a nutshell, IOC is an approach in which a separate object is responsible for populating the fields of other objects with correct implementations, instead of these other objects being responsible themselves. One benefit of this is that you can decouple an object from implementations by declaring the object's fields as interfaces (known as design by contract). Second, by removing creational logic from the object, you make the purpose of the object clearer.
An IOC container provides a framework that helps you adopt this pattern in a consistent and declarative way. Combining this strategy with interfaces can help you create objects that are testable and flexible. For a more in-depth description of the IOC pattern, see Martin Fowler’s article on Inversion of Control Containers and the Dependency Injection pattern.
Java and .Net IOC frameworks are already established, and recently there has been a lot of activity within the Flex community in this space.
In this article, I will describe some of these frameworks, providing a brief overview of how they work and how they compare to each other. To compare implementation requirements, I’ll be applying the Spring ActionScript, Parsley, Flicc, and Swiz frameworks to the same benchmark project, ProfileViewer.

IOC concepts

The two most common methods of configuring objects are:
  • Object instantiation (for example, myObject = new Object() )
  • Object lookup (for example, var myObject = registry.getMyObject() )
With IOC you instantiate the application objects in a separate layer and then pass dependencies into objects as they are needed. There are two common methods for this approach as well:
  • Setter injection (for example, instance.myObject = new Object() )
  • Constructor injection (for example, instance = new Instance( new Object() ) )
An IOC framework typically comprises three main pieces: the configuration, the factory, and the injection mechanism.
The configuration is where you describe how the objects relate to each other. The most common way of describing a configuration is by declaring it in a file. This file is sometimes called a context file. Configurations can also be described with metadata/annotations or programmatically.
The factory parses a configuration and prepares all the objects so that they can be retrieved once the application is running.
In classic Spring (the most popular Java IOC framework), all the objects that will be prepared by an IOC container (what I call client objects) declare their dependencies as interfaces. In the context file the declared dependencies are set to use specific implementation classes.
Injection mechanism
The injection mechanism is the means by which the instances created by the factory get injected into the application and injected into one another.
In Spring web applications this is done via the web.xml file, where Spring listens for the webapp context to be loaded. From here Spring hooks into the class loader, which then picks up any object that needs to be created. The factory will (if required) instantiate the object and populate it with all its dependencies, which in turn may need to be instantiated before returning the instance to the application (this is also known as “wiring it together”).
Class loading works differently in Flex, so the wiring needs to be done differently.
There are currently two options for this:
  • the client object can request a (wired up) object from the factory
  • an injection can be triggered by using the built-in Flex event mechanism that is used to initialize the views
This will be become clearer as you explore some of the frameworks.

Introducing ProfileViewer

The ProfileViewer project that I’ll use to compare frameworks is a very simple application made up of two screens: a login panel and a dashboard. ProfileViewer uses a simplistic Model-View-Controller (MVC) architecture and the Presentation Model pattern.
Note: This benchmark application is just an example; there are other ways that it could be coded. It is based on some popular patterns that I have seen on my travels. If you feel that I’m using a framework in a way for which it was not intended, let me know. I’d be happy to make adjustments based on feedback and suggestions for improvements.
Source code for all the samples is on Google code in the flex-ioc-examples project.
I strongly recommend that you have the source code open as you read the remainder of the article.
High-level architecture
The MVC pattern used by the application is commonly applied when developing graphical user interfaces. I won't go into the details of this pattern here, but if you need more information please see the Model-view-controller page.
On top of this I have implemented a Service Layer (see Figure 1). This is the integration point where the application gets data from the back-end system. In the sample, I stub this part of the application.
Finally, I'm using the Presentation Model pattern, in which the view has a model that contains its state and logic. The view then responds to changes in the state of this model, normally through binding expressions. This allows you to unit test the view logic. For more information see Martin Fowler’s explanation of the Presentation Model or Paul Williams’ post on the topic.
Figure 1. Initial architecture
Figure 1. Initial architecture

Identifying improvements
To change ProfileViewer to use an IOC framework, I will be moving the management of object instances and their dependencies to the IOC layer (see Figure 2). Some of the frameworks support wiring up events to actions, which enables you to set up a Controller layer. Where applicable, I will use what the framework provides.
Figure 2. Revised architecture with IOC
Figure 2. Revised architecture with IOC

Below, I briefly outline parts of the application that can be improved by harnessing the IOC.
Object lookup
When the user successfully logs in, the application gets two objects back. Details from these two objects are presented to the user in different views. When I prepare the Dashboard presentation model, DashboardPM, I perform a look up for the two object instances:
From MainPM:
public function set authenticated( value : Boolean ) : void { //.. var locator : ModelLocator = ModelLocator.getInstance(); dashboardPM = new DashboardPM( locator.user, locator.friends ); //.. }
In this case ModelLocator is a Singleton pattern that is used to store model objects.
By using a singleton I can access the same object instances anywhere in the application, because only one instance can be declared. In this case, I access User and Friends, safe in the knowledge that they are the same instances that are used elsewhere.
While this is useful, one of the downsides of working with a singleton is that it can make unit testing difficult because you have to be careful about the lifecycle of your objects throughout the duration of your test suite. This is because the single instance is stored with a static reference that persists between test cases and doesn’t become eligible for garbage collection.
Object pass-through
One way of minimizing the impact of using singletons in your application is by passing objects through hierarchies.
You can see this in action in the constructor for DashboardPM. It is expecting a User and a Friends model. The presentation model then passes these instances on to its children despite the fact that it is only making use of the User object. It is bad practice for an object to be dependent on another object that it does not use directly.
For a small example application, this might not be so troublesome, but as your application scales you can imagine that this method can require significant work. It also adds noise to your classes that needn’t be there. It would be cleaner if you could instantiate the object with the items that it needs.
Finally, the original ProfileViewer had a hierarchy within the presentation models so that I could do the object pass-through; because I no longer need this hierarchy with IOC I will remove it.
Configure service layer
The ability to configure non-view layers would be a useful enhancement to the sample application. In the example, this is represented by the LoginDelegate class, which creates its own RemoteObject instance.

Spring ActionScript

Framework: Spring ActionScript
Developer: Christophe Herreman
Version: 0.71
License: Open source
Configuration: XML
Spring ActionScript (formerly Prana), is one of the better known frameworks due to its maturity. It is developed by Christophe Herreman.
Core concepts
Spring ActionScript will be familiar to anyone who has used Spring’s .Net or Java equivalents. At runtime you load the configuration file. This gives the factory enough information to instantiate any object when they are requested by the application.
Basic Spring ActionScript configuration
There are three basic steps required to use Spring ActionScript on the benchmark project:
Create an application-context.xml file
Initialize the factory object in your application
Where required, pass objects from the factory for use within your views (or anywhere else)
Object factory and object configuration
With Spring ActionScript, object declarations are added to an XML file (usually called application-context.xml) that is accessible by your application. This configuration is then loaded by XMLApplicationContext, which is a subclass of ObjectFactory.
In my implementation, I’ve put this initialization into two objects: ContextLoader and Inject.
ContextLoader takes a path to the application context file. This loads in the XMLApplicationContext. In my application root I have:
private function init() : void { ContextLoader.contextPath = "application-context.xml"; }
Behind the scenes the ContextLoader is loading the Spring ActionScript context:
public static function set contextPath( value : String ) : void { _contextPath = value; applicationContext = new XMLApplicationContext( _contextPath ); applicationContext.addEventListener( Event.COMPLETE, handleLoadComplete ); applicationContext.load(); }
Then in the views that need dependencies, I have created an Inject tag (inspired by a colleague’s implementation in Parsley). Using this convenience tag, I can declare what dependency I’d like added to the view. For example, at the application root I have the following code:
<springActionscript:Inject property="pm" objectId="{ ContextIds.MAIN_CONTAINER_PM }"/> <springActionscript:Inject property="controller" objectId="{ ContextIds.CONTROLLER }"/>
This will ask the XMLApplicationContext for an object with an id of controller to be applied to the member variable controller in this view.
This is a nice way to retrieve the object from the view layer.
Note: Christophe Herreman has blogged about doing this type of injection using metadata (similar to the Swiz framework), but there are performance implications to this, since the view needs to be serialized to XML in order to read the metadata.
Setting up the controller
While Spring ActionScript plans to release an MVCS extension to the framework, for this version, I’m going to use my own hand-rolled controller and rely on Spring ActionScript to hook up the handler to the event source.
In the original application, the controller listens for events that bubble up the display list. When it receives an event, it does a lookup through its handlers to identify the object that can handle this event. In this modified example, instead of listening on the display list, I pair up the event source with the event handler in the application-context.xml file.
To do this, I added a new class, ControllerPair, that allows me to pair up the event source with a handler. This is then passed into SimpleController, which initializes each pair in its init() function.
<object id="controller" class="com.adobe.login.control.SimpleController"> <method-invocation name="init"></method-invocation> <property name="controllerItems"> <array><ref>controllerItem</ref></array> </property> </object> <object id="controllerItem” class="com.adobe.login.control.ControllerPair"> <property name="dispatcher" ref="loginPM"/> <property name="handler" ref="handler"/> </object>
Note the method-invocation tag, which allows you to declare functions that you would like to call on the object once it has been constructed. In this case I’m calling the init() function which binds up the event dispatchers to the event handlers.
Injecting the presentation models
In the non-IOC version of ProfileViewer, the presentation models were configured as a hierarchy to allow for object pass-through. I’m going to remove this hierarchy so that each presentation model can be configured just for that view.
While this makes the application much easier to configure and test, there is a downside. In some cases I will need to go the extra mile to hook up interactions between discrete presentation models.
Spring ActionScript supports both setter injection and constructor injection. I prefer constructor injection because it exposes the dependencies that the object needs to function. Below is the configuration for DashboardPM:
<object id="dashboardPM" class="com.adobe.dashboard.presentationModel.DashboardPM"> <constructor-arg ref="user"/> </object>
The constructor arguments declared in the XML are in the same order that the object constructor expects them. The ref allows me to refer to another object declaration within my context, in this case it is referring to the User declaration.
Configuring the service layer
LoginHandler contains a reference to the delegate object, which in turn has a dependency on a remote object, which will make the call to the back end.
I use setter injection to configure it. The domain instances are passed in, as is the delegate class and AuthenticationClient, which is the interface that checks if the user is logged in or not. MainPM implements AuthenticationClient.
In this instance, I stub the delegate, which is also configured with a remote object in the context file as follows:
<object id="handler" class="com.adobe.login.control.handler.LoginHandler"> <property name="client" ref="mainPM"/> <property name="user" ref="user"/> <property name="friends" ref="friends"/> <property name="delegate" ref="loginDelegate"/> </object> <object id="loginDelegate" class="com.adobe.login.service.LoginDelegate"> <property name="remoteObject" ref="remoteObject"/> </object> <object id="remoteObject" class="mx.rpc.remoting.RemoteObject"> <property name="destination" value="SPRING_ACTIONSCRIPT_DESTINATION"/> </object>
Spring ActionScript Summary
Spring ActionScript is a great, mature framework with an active development roadmap. The terminology that it uses should be familiar to anyone who has used Spring.
One thing that is troublesome about using XML to declare your objects is that sometimes you will declare a class in the XML and when this class isn’t included in the SWF (because there is no direct reference to it in your application), this will lead to a runtime exception being thrown by Flash Player. The solution to this would be to create an ActionScript class that declares dependencies from the context XML and include it in the application.


Framework: Parsley
Developer: Jens Halm
Version: 2.0.0
License: Open source
Configuration: XML/MXML/ActionScript
Parsley is another mature IOC framework that was originally inspired by Spring. It has recently undergone a major rewrite. The new version employs native Flex features like binding and metadata to give you greater options for configuring your project.
Core concepts
Central to Parsley is the idea of a context. This comes from Spring and refers to the dependency injection configuration for the application.
Configuration in Parsley is now available in a variety of options, including XML and MXML. You can use native MXML markup or custom MXML tags from the Parsley library. To enable the injection mechanism, Parsley uses metadata tags, similar to the Swiz framework.
Parsley comes with messaging patterns too. With very little intrusive code, you can enable your objects as event sources or event handlers. I used this capability in this example instead of using the Controller pattern.
Basic Parsley configuration
There are three basic steps to Parsley configuration:
Create a Config.mxml file
Initialize a Context in the root of the application
Add the Inject metadata to the dependencies in your views.
Although there are other options as to how you prepare your configuration file, for this example I'm using an MXML file with native markup and Parsley tags. This approach has the benefit of including classes at compile time at the expense of not being able to update the configuration of an already compiled application.
Object factory and object configuration
In the Config.mxml you will see all the application objects, from domain models to delegates. They are declared in two ways:
In standard MXML
Using Parsley's object definition tags
I will go into more detail of these two types in a later section.
Setting up the controller (and LoginHandler)
Instead of using my hand-rolled controller, I have used Parsley's messaging system, which is designed to have a minimal impact on the objects that you write. It makes use of metadata to do this. An object that is visible to the Context and has this metadata will allow Parsley to wire up the event source to the event handler.
In the example application, LoginPM is the event source, and LoginAction (which I've renamed from LoginHandler) is the event handler.
Here is an excerpt from LoginPM:
[Event( name="LOGIN", type="com.adobe.login.control.event.LoginEvent")] [ManagedEvents("LOGIN")] public class LoginPM extends EventDispatcher { ... public function login() : void { var event : LoginEvent = new LoginEvent( username, password ); dispatchEvent( event ); } }
The three items that enable this as an event source are the Event metadata tag, the ManagedEvents metadata tag, and EventDispatcher#dispatchEvent. Of these three, only ManagedEvents is a Parsley-specific addition. The Event metadata is just good practice, and dispatchEvent is required to do the work. Parsley will use ManagedEvents to determine which events it needs to handle and delegate to event handlers.

Here is an excerpt from LoginAction, which has been configured as an event handler:
public class LoginAction implements IResponder { [MessageHandler] public function execute( event : LoginEvent ) : void { ... } }
Because I added MessageHandler metadata to this function, Parsley will add this object/function as a listener to any event of type LoginEvent.
To make these objects visible to Parsley, I can declare the object within the configuration file that I pass into FlexContextBuilder or I can use the Configure object in my views.
Injecting the presentation models
As with all the examples, I’ve made the presentation models nonhierarchical. See the explanation in the Spring ActionScript section for more information.
Parsley supports both setter injection and constructor injection. As I noted with the Spring ActionScript example, I prefer constructor injection because it exposes the dependencies that the object needs to function. Below is the configuration for DashboardPM:
<spicefactory:Object type="{ DashboardPM }"/>
If your object requires constructor arguments, you’ll want to declare it using an Object tag because such arguments are not supported in native MXML.
To complete the constructor, you add some metadata to your class:
[InjectConstructor] public class DashboardPM { public var user : User; public function DashboardPM( user : User ) { this.user = user; } ... }
The metadata tag InjectConstructor instructs Parsley to inject a declared object of type User into the constructor of DashboardPM.
For setter injection you just need to add the Inject metadata tag to your classes. For example, I declare SummaryPM in standard MXML inside Config:
In the class file, I then have:
public class SummaryPM { [Inject] public var friends : Friends; ... }
The Inject tag indicates that an instance of type Friends needs to be injected into this instance.
Parsley summary
Inspired by some of the innovations that the other frameworks have pioneered, the new version of Parsley is a complete IOC framework. It also supports modular development to support unloading of contexts. This is an important feature for a growing number of Flex applications that make use of modules.


Flicc is one of the lesser known and more recent arrivals in the IOC space. It takes a slightly different approach, using an MXML file for configuration. It also has its own markup for object definitions in the MXML, which gives you the option of passing pre-existing objects into the factory to have their dependencies added (for example passing in a view).
A benefit of declaring your dependencies in MXML is that they are added to your application during compilation, instead of potentially causing runtime exceptions when you run the application and the dependencies are missing. A drawback is that dependencies cannot be changed without recompiling the application.
Object factory and object configuration
In Flicc you add a Configure tag to your views to allow you to pass in instances to be configured. You can also pass in existing instances and have them configured, much like the Inject tag that I used in the Spring ActionScript implementation.
Basic Flicc configuration
  1. Create a configuration class that subclasses MXMLObjectFactory.
  2. Initialize a Flicc instance and pass in the configuration.
  3. Where required, add the Configure tag to your views.
<FliccListener> <MxmlObjectFactory> <Config/> </MxmlObjectFactory> </FliccListener>
The main MxmlObjectFactory tag is added to the application root. It is wrapped by a FliccListener tag, which allows Flicc to pick up events being dispatched by Configure tags that are sitting in the application’s display list. Config.mxml is my own configuration file.
Setting up the controller
Similar to Parsley, Flicc allows you to wire up events to objects in the configuration file, although it doesn’t use the concept of a controller.
I’ve used this to wire up the controller to the event source, which is LoginPM. When LoginPM dispatches its event it is picked up by the controller, which in turn calls the appropriate handler.
<Object objectId="controller" clazz="{ SimpleController }"> <handlers> <EventHandler eventName="{ LoginEvent.LOGIN }" handler="handleEvent"> <source> <Ref to="loginPM"/> </source> </EventHandler> </handlers> <handlerArray> <List clazz="{ Array }"> <Ref to="loginHandler"/> </List> </handlerArray> </Object>
In the controller we look up the event for the event type and invoke execute.:
public function handleEvent( event : Event ) : void { getHandlerForEventType( event.type ).execute( event ); }
Injecting the presentation models
In this example too, I remove the hierarchy between the presentation models.
Flicc allows you to do both setter injection and constructor injection.
Flicc has two basic object tags: Component and Object. Component is for describing existing objects that you want to configure. Object creates a new instance. For example:
<Object objectId="dashboardPM" clazz="{ DashboardPM }"> <constructor> <Ref to="user"/> </constructor> </Object>
As with Spring ActionScript and Parsley you declare the arguments for the object constructor in the order that the object expects them. Ref is a reference to another object that is declared within the context that is identified with the to attribute.
A Component looks similar, except that you only use setter injection, because the Component describes an object that already exists and is passed into Flicc:
<Component objectId="main"> <controller> <Ref to="controller"/> </controller> <pm> <Ref to="mainPM"/> </pm> </Component>
In the Component, I populate the main application, which has a controller and a pm variable.
Configuring the service layer
LoginHandler is dependent on LoginDelegate, which in turn is dependent on RemoteObject.
Here is the configuration:
<Object objectId="loginDelegate" clazz="{ LoginDelegate }"> <remoteObject> <Ref to="remoteObject"/> </remoteObject> </Object> <Object objectId="remoteObject" clazz="{ RemoteObject }"> <destination> FLICC_DESTINATION </destination> </Object>
The code above declares a new instance of LoginDelegate and populates it with RemoteObject.
Flicc summary
While Flicc is different from the previous two frameworks in that it uses MXML as the declaration format, under the hood all frameworks follow the same basic principles.
Declaring your configuration in MXML can be a time saver when you are developing because the classes are compiled with the application and you don’t have to handle loading and parsing an external file. The API is different from the previous two frameworks and takes some getting used to.


  • Framework: Swiz
  • Website:
  • Developers: Chris Scott, Sönke Rohde, Ben Clinkinbeard & Darron Schall
  • Version: 0.6.2
  • License: Open source
  • Configuration: MXML + Metadata
Swiz has been available since early 2008 and has a strong following. It is more than just an IOC; it is meant to be a complete solution for Rich Internet Application (RIA) architecture. Swiz uses MXML for defining objects, but has a different injection mechanism.
Core concepts
Swiz provides a class that you eases the initalisation of the application SwizConfig. This class takes in a configuration file that is loaded into the Swiz instance. The configuration file uses standard MXML declarations and a custom tag Prototype that can be used to create objects that take constructor arguments. For defining injections, Swiz reads metadata from the classes themselves to determine which objects to inject where. This is an approach popularized in the Java world by the Annotations support in Spring 2.5 and latterly Google Guice.
Using metadata makes your objects more meaningful and your configuration files a bit cleaner.
Basic Swiz configuration
  1. Create your beans file
  2. Add a SwizConfig to your application and pass in the beans file
  3. Add the metadata to the classes into which you want to inject dependencies
With Swiz, you load your beans in your application root:
<swizframework:SwizConfig strict="true" mediateBubbledEvents="true" beanLoaders="{[ AppBeans ]}" viewPackages="com.adobe.login.view,com.adobe.dashboard.view" logEventLevel="{ LogEventLevel.WARN }"/>
You then have two options. You can request the beans from Swiz:
Swiz.getBean( "loginHandler" )
Or you can use metadata:
[Autowire] public var pm : DashboardPM
For a full list of possibilities see the Swiz documentation. One thing to remember about the metadata injection is that the class needs to sit on the display list or be declared within your BeanLoaders or else the injection won’t take place. The code snippet above is from DashboardPanel.
Under the hood, Swiz listens to any object that gets added to the display list, and then uses reflection to see if the object contains any injection metadata. This requires serializing the object to XML in order to read the metadata, which can have performance implications. To mitigate this you can limit which classes get inspected at a package level by specifying a package by using the viewPackages property on SwizConfig.
Setting up the controller
Swiz has a nice feature that allows you to nominate functions to handle events that are dispatched through the Swiz mechanism.
In LoginHandler I’ve added the following metadata:
[Mediate(event="LOGIN", properties="username,password")] public function login( username : String, password : String ) : void
Then in the event source (LoginPM), I dispatch the event as follows:
dispatchEvent( new LoginEvent( username, password ) );
For this to work you need to enable mediating bubbled events in SwizConfig. This means that Swiz will listen to events that bubble up the view hierarchy. If you don't enable mediating bubbled events you can use:
Swiz.dispatchEvent( new LoginEvent( username, password ) );
However this explicitly ties your code to the framework.


The ProfileViewer application doesn't make any true asynchronous requests, where Swiz provides you some useful classes to manage these calls. The AbstractController provides a method "executeServiceCall" that will generate a dynamic Responder object saving you from having to write up this boilerplate code yourself. Swiz also provides a TestUtil class that allows you to create mock service calls and results.
Injecting the presentation models
Just as I did with all the frameworks, I configured the presentation models to be nonhierarchical. Here are the definitions:
<local:MainPM id="mainPM"/> <login:LoginPM id="loginPM"/> <factory:Prototype id="dashboardPM" xmlns:factory="org.swizframework.factory.*" classReference="{ DashboardPM }" constructorArguments="{[ user ]}" />
The declarations are standard MXML declarations. The Prototype tag allows you to describe an object instead of creating an instance. This allows you to passing constructor arguments into the object. The wiring is done in the classes:
public class MyClass { [Autowire] public var myDependency : MyModel; … }
Swiz will attempt to autowire by type, meaning that you must have exactly one bean of a matching type defined. If you have zero or more than one bean of that type you must specify a bean name. Note that in LoginController has a dependency on AuthenticationClient, which is an interface that MainPM implements.
Configuring the service layer
For this sample I'm renaming LoginHandler to LoginController. This is because it is going to extend Swiz's AbstractController:
public class LoginController extends AbstractController { [Autowire] public var client : AuthenticationClient; [Autowire] public var user : User; [Autowire] public var friends : Friends; [Autowire] public var delegate : LoginDelegate; [Mediate(event="LOGIN", properties="username,password")] public function login( username : String, password : String ) : void { executeServiceCall( delegate.authenticate( username, password ), result ); } }
AbstractController provides you with a function: executeServiceCall, that will automatically add result and fault listeners to the Asynchronous call. You specify a result handler and optionally a fault handler. This saves you from having to write boilerplate code yourself.
The delgate is slightly different from the other samples. This is firstly to show AbstractController in action, but also to demonstrate another Swiz function: TestUtil.mockResult. This helper function will mimic an asynchronous request, which is useful when you are developing without having a backend to call back to.
public class LoginDelegate { //only included for illustrative purposes //to show that swiz has configured it correctly. [Autowire] public var remoteObject : RemoteObject; public function authenticate( username : String, password : String ) : AsyncToken { var mockResult : * = { user : MockModelFactory.createUser( username ), friends : MockModelFactory.createFriends() } return TestUtil.mockResult( mockResult ); } }
Swiz summary
Swiz takes a novel approach to defining your injections. It has many features that aim to simplify the development process, by removing the need for boilerplate code and so helping you to focus on the business end of your appliction.

Where to go from here

This article provided a quick walk through of some of the better known IOC containers available for the Flex framework. Some notable frameworks that were not included are Mate and SmartyPants. Mate allows for IOC, but it also offers more than that. While I did start preparing a Mate sample for this article, I wanted to learn more before writing about it. I will flesh out the Mate sample on Google code. SmartyPants is similar to Swiz in that it uses metadata to describe the injections, and it is worth a look.
I hope this was informative, firstly as a primer on how IOC can be used in your Flex application, and secondly as a comparison of the various frameworks. It was not possible to mention every feature of each of these frameworks, so I recommend that you check out each framework’s documentation for more details.