thanks,
Hari

I see what you mean, your use of ILoginModel is simply an illustration that the use of interfaces is a good thing. I can’t disagree.

My main point was that your approach is not what most people would call “dependency injection”. When I came here, I was hoping to see a simple dependency injection framework – where I don’t have to implement a factory or abstract factory (or a “factory factory”) to manage dependencies.

Yes Cairngorm does seem to “encourage” strong coupling between components. And I agree Swiz is a great framework and I enjoy it but I wanted to point out that with Cairngorm it is pretty simple to alleviate the pains of strongly typed coupling.

I guess I was moreso talking about using the dependency pattern and not necessarily setting up a whole dependency injection framework so “when a class satisfies its own dependencies it becomes inflexible with regards to these dependencies.” Meaning that by having a view look for its model by:

private var loginModel:LoginModel = AppModelLocator.getInstance().loginModel;

The view is now tightly coupled to the the “AppModelLocator” and is inflexible so if you have to change the dependencies you will have to change the code. But with some simple refactoring:

public var loginModel:ILoginModel;

Now the view no longer satisfies these dependencies itself and becomes completely independent and reuseable just by implementing an interface.( I didn’t mention it in my post but this is also extremely helpful when it comes to unit testing.)

As regards to using the Factory pattern and the “init()” function, in this particular post I just wanted to make it simple but it would be easy enough to set up an abstract factory pattern implementation.

And yes I agree the model can typically be concrete but I wanted to show that with interfaces you can use different parts of your model according to where it is implemented. Unfortunately Actionscript does not inherently support Abstract classes and we can only extend 1 class at a time, but we can implement multiple interfaces and interfaces can extend multiple interfaces.

I recently reviewed all four frameworks you mentioned. I’ve found Cairngorm lacking because its design seems to encourage developers to strongly couple application components. I have decided to use the Swiz framework for the first Flex project for my team. I see that you have used out Swiz before. Swiz does a good job at allowing code to be loosely coupled via autowiring and dependency injection. Is it possible that the use of Swiz framework, plus a MVC pattern similar to Cairngorm, will do a better job at simplifying your code?

Looking at your code, I’m wondering what you mean by dependency injection. The dependencies are still embedded in the code (in this case, the view). The dependency injection pattern means that the glue code (or code that specifies dependencies of each object) are moved to a central location and that the dependencies of the object graph is automatically maintained for you.

To be brief, the technique used by you is more like the Factory pattern, where a method defines the relationship of the objects in your framework.

Specifically, following code more or less defines your factory object/method :

private var appModel:AppModelLocator = AppModelLocator.getInstance()
…
appModel.loginViewModel = new LoginViewModel();

Note that these few lines strongly couples your view (or Factory object) to the AppModel and the ILoginViewModel implementation.

I noticed your code has a very simple model, and your use of the init() method easily sets up everything you need.

ModelLocator -> ILoginViewModel

Contrast to your example, a dependency injection framework typically deals with more complex object graphs, for example:

ModelLocator
+ — ILoginViewModel
+ —- IUserModel
+ —- IUserPasswordModel
+ — IUserPreferenceModel
+ —- IUserAddressModel
+ —- CountryImpl
+ —- StateOrProvinceImpl
+ —- StreetAddressImpl
+ —- IUserBlogPerefencesModel
+ —- …
+ —- IUserOpenLoginPerefencesModel
+ —- …

Imagine what your init() method will have to do to set up something like that!

I know, this is an extremely contrive example; the intend is to show you how complex the glue code can get. A dependency injection framework aims to simplify that kind of glue code, and allows you to define the dependencies in a central location. Swiz, Guice, and the Spring framework can give you an idea how dependencies are managed by the framework, instead of managed by code.

Not that there is anything wrong with the Factory pattern. However, just be aware the typical cons of the Factory pattern can apply to your technique. For example, if the Model has a complex object graph, your init() can get very complicated, and the developers working on this application may be tempted to have similar init() in other views (modules or other .mxml files), which puts the glue code in multiple places, making the code harder to organize.

A second opinion from me is that, based on my experience, the Model can typically be concrete; Models do not need dependency injection. This is because the _implementation_ of the Model typically doesn’t need to change. Where dependency injection comes in handy is at the business logic layer, where you may have multiple implementation of the same interface, or an interface where the implementation can change frequently. In a Flex application, what is more likely to change is how events are dispatched. As example, a complicated command with dependencies to multiple services (HttpService, RemoteObject, maybe a BlazeDS consumer/producer) is something where the dependencies should be managed by a framework, since the services associated with the command may change frequently due to changes in business rules.