Just wrote an article that questions the preference towards constructor injection by investigating IoC (like you have also done here), API Design, and other factors in the big picture of coding the application.
 http://tech.finn.no/2011/05/13/dependency-injection-with-constructors/

I fully agree! I should point out that most of my thinking has been in the realm of architectural/application framework design (see: RobotLegs).

I’m hoping that SmartyPants-IOC introduces constructor injection soon (it has been rumoured). Well, actually I’m hoping that someone releases a DI framework with no Flex dependencies that supports both constructor and annotated setter injection

For my framework actors (modelled on PureMVC) I’m happy with annotated setter injection – as the actors are mostly just hookup/decoupling/bridge points and tend to change quite a bit as an application grows. Once an application’s architectural design has settled down, however, I would like to be able to refactor to constructor injection.

I fully agree! I should point out that most of my thinking has been in the realm of architectural/application framework design (see: RobotLegs).

I’m hoping that SmartyPants-IOC introduces constructor injection soon (it has been rumoured). Well, actually I’m hoping that someone releases a DI framework with no Flex dependencies that supports both constructor and annotated setter injection

For my framework actors (modelled on PureMVC) I’m happy with annotated setter injection – as the actors are mostly just hookup/decoupling/bridge points and tend to change quite a bit as an application grows. Once an application’s architectural design has settled down, however, I would like to be able to refactor to constructor injection.

One area where constructor injection becomes very useful is with existing code. If classes require their dependencies in the constructor there is no need for language constructs like smarty-pants’ [Inject] meta-data in order to enable the injection. This makes it easier to use existing code libraries with a DI container if the container uses constructor injection.

On the other hand, due to the method of their construction, it’s difficult to use constructor injection with Flex components.

Because MXML pushes us towards constructors with no parameters, I’m inclined towards setter injection for Flex projects. But it does frustrate when one wants to use DI with an existing open source library like Away3D or my own Flint.

One area where constructor injection becomes very useful is with existing code. If classes require their dependencies in the constructor there is no need for language constructs like smarty-pants’ [Inject] meta-data in order to enable the injection. This makes it easier to use existing code libraries with a DI container if the container uses constructor injection.

On the other hand, due to the method of their construction, it’s difficult to use constructor injection with Flex components.

Because MXML pushes us towards constructors with no parameters, I’m inclined towards setter injection for Flex projects. But it does frustrate when one wants to use DI with an existing open source library like Away3D or my own Flint.

Should the order in which we are given our dependencies ever be important?

I don’t think so. What’s important is that our dependencies be entirely satisfied at some point, and that we know when that point is: so that we can consider ourselves “fully” constructed or “ready” and get on with things.

The order of instantiation of the dependencies themselves might be important, but that is not our concern – that is the concern of the container. That’s context stuff, and shouldn’t matter to us inside our class where we have a specific job to do.. when we’re “ready”.

And how do we know when we’re ready? Well, that’s the murky part.. “When we’re told so”.

I might well be overlooking something, but I hope not.

As for the SmartPants-IOC setter vibes.. yes,.. “properties which should really be private are made public to satisfy the injection framework”. Yeh, I know what you’re thinking!.. But is that really so bad when one views dependencies as immutable properties? – set during the construction phase, and never altered thereafter.

Manipulating objects (changing their state) from the outside isn’t such a good idea most of the time anyway – it puts knowledge in the wrong place and is often responsible for tight coupling. Properties don’t make for good API’s. Here, properties are bad.

On the other side of the fence live Value Objects. No logic, no methods, no access control, just complex, nested, value types.. value structures. Public properties. Here, properties are good.

To help me sleep better, I just lump dependencies in the same conceptual bucket as Value Objects.. and hope that the nagging feeling fades over time!

Should the order in which we are given our dependencies ever be important?

I don’t think so. What’s important is that our dependencies be entirely satisfied at some point, and that we know when that point is: so that we can consider ourselves “fully” constructed or “ready” and get on with things.

The order of instantiation of the dependencies themselves might be important, but that is not our concern – that is the concern of the container. That’s context stuff, and shouldn’t matter to us inside our class where we have a specific job to do.. when we’re “ready”.

And how do we know when we’re ready? Well, that’s the murky part.. “When we’re told so”.

I might well be overlooking something, but I hope not.

As for the SmartPants-IOC setter vibes.. yes,.. “properties which should really be private are made public to satisfy the injection framework”. Yeh, I know what you’re thinking!.. But is that really so bad when one views dependencies as immutable properties? – set during the construction phase, and never altered thereafter.

Manipulating objects (changing their state) from the outside isn’t such a good idea most of the time anyway – it puts knowledge in the wrong place and is often responsible for tight coupling. Properties don’t make for good API’s. Here, properties are bad.

On the other side of the fence live Value Objects. No logic, no methods, no access control, just complex, nested, value types.. value structures. Public properties. Here, properties are good.

To help me sleep better, I just lump dependencies in the same conceptual bucket as Value Objects.. and hope that the nagging feeling fades over time!