While researching technologies for a new "pet project" I analyzed a few well-established project's source code and I noticed that they hardly use any dependency injection frameworks at all. For instance, Hazelcast and Cassandra don't seem to use any. The only big name I could find which seems to use one is Elasticsearch. I wonder why this type of framework isn't used in big, standalone "server" projects. Is it for performance reasons? Is it to avoid coupling code to a particular framework? When can using such frameworks become dangerous?

  • 1
    A comment on the reason of the downvote would be much appreciated... Commented Mar 21, 2016 at 10:45
  • 8
    It doesn't have to be dangerous to be a bad idea. It just has to add more costs than benefits. Commented Mar 21, 2016 at 10:52
  • 2
    I think the idea that dependency injection (and even more so dependance injection frameworks) are appropriate for all circumstances is the biggest weakness of dependancy injection Commented Mar 21, 2016 at 19:32

2 Answers 2


Here's the only Dependency Injection you'll ever need:

public MyConstructorMethod(MyDependencies) { }

Simple, isn't it?

So why have DI containers then? Well, would you rather say this

var svc = new ShippingService(new ProductLocator(), 
   new PricingService(), new InventoryService(), 
   new TrackingRepository(new ConfigProvider()), 
   new Logger(new EmailLogger(new ConfigProvider())));

or this?

var svc = IoC.Resolve<IShippingService>();

Granted, this is an oversimplification. DI containers manage a certain kind of complexity, but add some new complexities of their own. In example 2, how do you know what is being injected if you have a problem that you need to troubleshoot? Also, if your dependencies are as complicated as example 1, you probably should address that complexity first.

In my opinion, DI containers only prove their worth in applications having very large, complex object graphs. This might explain why you don't see them in small to medium-sized frameworks.

Further Reading
Inversion of Control Containers and the Dependency Injection pattern
Why do I need an IoC container as opposed to straightforward DI code?

  • 4
    I would argue that if your ShippingService looks like that, IoC isn't going to fix the problems there - it just hides it.
    – Telastyn
    Commented Mar 21, 2016 at 13:50
  • 1
    Oh, no argument there. Commented Mar 21, 2016 at 13:50
  • In your IoC.Resolve example, can you mention where the definition takes place which IProductLocator or IPricingService implementation the framework will pick?
    – Doc Brown
    Commented Mar 21, 2016 at 14:00
  • @DocBrown: programmers.stackexchange.com/q/313391 Commented Mar 21, 2016 at 17:34
  • Does this answer the question; why they didn't use dependant injection Commented Mar 21, 2016 at 19:34

Yeah, complexity. A DI framework makes the code more complex and complexity makes code more error prone and more expensive to maintain. But on a sufficiently complex system, a DI framework makes it easier to manage dependencies and to unit test, which in turns makes it easier to maintain. So it is always a question of trade-offs and to determine at what point the benefits of adding a DI framework outweighs the cost. This is not always easy to determine.

I wouldn't say a DI frameworks can be dangerous though. Even in cases where it is overkill, it will mostly just be a drag, but it is not going to sink the project. Only if it is a symptom of an overall tendency to overengineer everything, it becomes a danger.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.