For example:

In a simple MVC app. I have my CustomControllerFactory locate my controllers. My controllers have constructor dependencies on some Services. My Services have dependencies on infrastructure objects (repository, etc…).

The only place my app has a dependency on the container is in the CustomControllerFactory. The container is totally transparent.

Start throwing your service locator everywhere, you're bound to have a problem.

For example:

In a simple MVC app. I have my CustomControllerFactory locate my controllers. My controllers have constructor dependencies on some Services. My Services have dependencies on infrastructure objects (repository, etc…).

The only place my app has a dependency on the container is in the CustomControllerFactory. The container is totally transparent.

Start throwing your service locator everywhere, you're bound to have a problem.

I guess if you are writing a framework or code that will be used by others then it makes sens to go with constructor injection because it is explicit what interfaces are the class dependent.

If I used a property that automatically creates the interface from IoC container i.e. Kernel.Get…., it will work just the same but then the consumer of that class doesn't know that. He doesn't know which interfaces need to be configured in his IoC container configureation and so on…

What if we can configure a class like this:

[Inject(IService1, IService2, IService3)]
class MyClass

This way, I don't have to “pollute” my constructor and it is still somewhat discoverable and predictable. What do you think?

It isn't so obvious when you're in 'author' mode, because at that point you're intimately familiar with the class's internals and don't find any of its interactions with the rest of the system 'surprising'.

As a user or maintainer of a class, however, you need to be aware of both the provided interfaces, and the required interfaces *equally*. Otherwise, you can have a very hard time when trying to determine exactly how methods called on that class will affect the rest of the application.

Provided interfaces -> interface implementations
Required interfaces -> constructor parameters

The second isn't necessarily any less important than the first.

(Properties can't be used to emulate the same role, as it is impossible to determine from a property declaration whether the property represents a required interface or just exposes functionality provided by an aggregated component.)

Hope this helps!

Nick