Are there any reasons not to use a DI framework on a standalone project?

Question

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?

Answer 1

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?

Answer 2

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.