Fear of using a Dependency Injection framework

Question

I have been reading up on Dependency Injection frameworks. I really fell in love with the idea of separating the concerns and letting the objects do their core work - which is undoubtedly an excellent and long-standing design principle!

However the more I read on DI frameworks, the more I get worried: 1) In the way they "automagically" resolve dependencies 2) About the extreme complexities being introduced in the configuration files

On just the point #2, I have seen my customers spend millions of dollars to train the people on products of which the significant part was how "not" to touch config files. The administrators are now dreading these config files.

Nevertheless, I see another pattern called Service Locators where I could nicely assemble all the "global" services that I want at the start of my application (may be an application host or app context or whatever). Make this service locator globally available and voila!

However I see that there will be less flexibility when using the Service Locator approach when I need more than one type of "global" service based on some criterion (known to whom?)!

So, here I am more confused than before on which direction to take. Though I like the design principle very much, the complexity in the existing frameworks are throwing me off!

Are my concerns genuine? Anybody else feel the same? If so, is there any good alternative for such massively overwhelming "frameworks"?

Answer 1

I personally quite enjoy using Autofac. The container configuration is done through code, at the same time eliminating verbose XML and enabling refactoring support.

One of the best features, though, is modules. They are units of container configuration, allowing you to manage the complexity of the many different components which comprise your application.

I am currently working on a very large project, and the experience is roughly the same as when it was small, meaning this approach scales very well.

A main tenet of DI-enabled classes is that they do not reference infrastructure code. This is the antithesis of the Service Locator pattern. The main downfall of Service Locator is that, in addition to adding complexity to classes which reference the container, there is no ability to change which version of a dependency is resolved.

With "pure" classes that don't reference a container, the resolved version of any given dependency is external to the class being injected.