IoC Frameworks can’t do it alone
The community around the Flash Platform is fast moving. You can’t keep up to date on everything that is being done. But as a consultant and a community leader I feel its my job to at least know a little bit about a good portion of what is out there.
This week I have been playing around with some of the IoC (Inversion of Control) and DI (Dependency Injection) frameworks available for Flex and AS3. I have never done java as a full time gig so most of my IoC knowledge comes from reading about Spring and using ColdSpring in CF. I don’t know how to utilize everything that Spring brings to the table but I have a really good base around IoC.
IoC allows you to change who is responsible for object creation in your application. It allows you to have the external classes your business and views are dependent on “injected” for you. So you can create a controller and a delegate and whatever classes your application needs and have them hotwired into the objects that need them without having to instantiate them directly. There are several benefits to this but I will save those for another day.
The thing I want to share is a concern I developed while researching the new tools available. Saying you use Swiz, or Prana in your application doesn’t actually tell anyone about the structure of your application. These frameworks are built around providing a solution to dependencies on other classes. They are not MVC frameworks. And as such as a consultant they are not a complete means to an end. Now they could be the only external framework you use in an application, but you would still need to document the architecture of your application for others. That is compared to say a Cairngorm application where people will expect to look in the commands for the logic around a particular piece of work. Saying you use an IoC framework does not help people understand how your application behaves. In fact depending on which features of those IoC frameworks you use, it could be harder for someone to join your project without a significant learning curve. Just an example of this would be with Swiz, you can either autowire your controller into your view ( something i consider dirty and to be avoided at all cost), you can use the Swiz central dispatcher, and beyond that you can have it automatically wire event handlers to events. So saying you use Swiz only gives me a glimpse into how your application might be structured.
As such the spring-as (Prana) framework actually includes some extensions to help make it more useful with Cairngorm and PureMVC. And while I am not aware of anything specific in Swiz for such an end, I am using it to wire up the delegates for my command and it works great!.
So your take away from this is that and IoC framework must still be utilized with some kind of MVC architecture in order to be useful in an application. Be that a Flex event based, homegrown, or open source framework, IoC can help simplify object dependency creation. But it is not a replacement for MVC in your application.
I couldn’t agree more. Swiz is a fantastic tool and I’m enjoying it immensely. But it is NOT an MVC framework. The Swiz folks themselves usually refer to it as a micro-framework. You can obviously use Swiz while doing MVC, but just as easily you could pass on MVC altogether.
I would love to see an opinionated MVC ActionScript framework out there that used Swiz’s “brutally simple” dependency injection and event handling. PureMVC is great, but my current projects don’t need the added complexity and overhead of avoiding Flash/Flex libraries.
Swiz and Spring-AS are really cool steps forward. But I agree with you that they can’t do it alone. That’s not a knock on either of those tools, it’s just a recognition that we’ve still got some work to do.
Excellent post! I have recently been investigating various IoC/DI implementations (swiz and prana) to use in my own “home grown†application framework. These tools provide elegant solutions to very real problems but are only pieces of the total application architecture. After your review, what were your thoughts concerning the current DI implementations available in AS3? You mentioned that in some context you found swiz autowire implementation dirty (which I think I agree with) yet (if I understood correctly) you do use it to wire up delegates for your commands in Cairngorm. In your opinion, did you find any compelling reasons to use one implementation over another?
Hey Walter,
I Love Autowrie. I think the DI via metadata is killer.
What I don’t like is wiring your controller into your view. I don’t think that your views should call methods on the controller directly. I think this creates a coupling that is hard to overcome.
I think using the central dispatcher and using the injection to wire up dependencies is great though.
As far as one over the other…Chris Scott is a friend so I lean towards wanting to use Swiz. I think the autowire stuff is just top notch. But Prana has a longer history and more documentation. As well as prana now being supported by Spring as the AS extension.
I am still on the fence over which one I like better. I am currently looking at the examples from prana and seeing if there is anything I can’t do with Swiz. So far thats a no, but I want to make sure.
Have you had a look at SmartyPants-IOC (inspired by Google’s Guice DI framework for Java)?
http://code.google.com/p/smartypants-ioc/
I fully agree with the gist of your post. I’ve actually used SmartyPants to build an MVC framework much like PureMVC – but without the boilerplate code, Singletons, service locator, or custom notification scheme.
I checked out Swiz, but I think that the central dispatcher, although useful, is a really bad idea. And I agree that directly referencing a controller from a view component is dirty.
Personally, I’m a fan of using annotations for dependencies, but I don’t think that view components should have any direct application dependencies, and therefore should not be candidates for Autowire.
Spring ActionScript, while certainly powerful, annoys me with it’s external XML configuration files and lack of direct Autowire functionality (although this can certainly be cooked in).
What I like about SmartyPants-IOC is that it’s not trying to be anything other than a Dependency Injection framework – which can not be said for Mate or Swiz.
By keeping my MVC framework, DI framework, and application actors independent I have the ability to swap any one of them out without breaking my application. Happy vibes!