Emad Ibrahim

I'm with Mike.

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.

Mike,
You wrote, "I've got applications that leverage an IoC container but the only place where the IoC container is referenced is on application startup.".
Can you explain how you accomplish this?
Thanks!
Lee

I don't like your property implementation at all. You now have an explicit dependency on the IoC container. Remember IoC is 90% about the IoC/DI pattern and only 10% about the mechanics of how your IoC container works. I've got applications that leverage an IoC container but the only place where the IoC container is referenced is on application startup. I think constructor injection makes perfect sense, rather that polluting a service implementation it's making explicit its dependencies.

The benefit that ctor injection brings is more about predictability than discoverability.

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

Ok that makes perfect sense and was sort of what I was thinking but you expressed it much better.

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?

Starting to get well into 'service locator' territory here - there's a lot of discussion out there about the relative merits of each.

I'm not sold on constructor injection either. It seems like the biggest argument for it is discoverability, but I just kind of feel like it dirties up my classes for some reason. For the same reason, I've been enjoying Autofac's support for property injection without having to use any [Inject]-style attributes.