Dependency Injection vs Singleton Pattern

Question

I just read documentation and tutorial about dependency injection (DI) and the singleton pattern (SP). Everybody seems to says DP is bad and DI is the way to do it. Tutorials about dependency injection use some framework like Autofac or Ninject. They also all explain DI don't need a framework, container. I understand.

Actually DI is not complicate. You create an interface then you pass the implementation of your interface to the constructor.

But always come the moment where they explain that with Autofac or Ninject or other container you must define the lifetime of you class. So you have this line

kernel.Bind<MyFacade>.To<MyFacade>().InSingletonScope(); 

And again yes. DI is simple but in the simple version of DI there is no Singleton. So when you want to use DI for singleton behavior you must use a container, right? So at the end the container is just managing the single stuff for you, right?

So DI is not something we should oppose to SP. DI with container is something I can oppose to SP.

So at the end why I should not use SP by myself but trust a library to do it? What is the difference between DI using container with single scope and SP?

Answer 1

You're correct that the idea of DI is to be able to rely on an abstraction (interface) rather than a concrete implementation, but that is only one piece of the puzzle. You still need to instantiate the actual object somewhere else, before passing in to a constructor or injecting it. The bigger part here is how you create that instance. Since simply new-ing up the object still keeps you tied to that specific implementation, it's recommended instead to use a pattern such as a factory. Using a DI container just makes it easier and allows us to not reinvent the wheel, but of course you can do whatever suits your needs best.

Now, if you only have a couple classes or a small project, then maybe just using the singleton pattern on your own is perfectly acceptable. It all comes down to preference.

Answer 2

So you need to construct something once only. Fine. Have access to main? Great. Build it in main once. Main is only called once. Pass it to everything that needs it. Call that passing "dependency injection" if it makes you feel fancy. Done.

Don't have access to main because you're using some annoying framework? Find any method that is called once and only once. Use that as your "composition root". It's usually found as high up the call stack as you can get.

Don't have access to a method that is only called once? Well like it or not, now you're stuck with the singleton pattern. It works as well as it ever did. This isn't it's fault. You're just stuck in a crappy situation. Maybe stop using crappy frameworks.

Answer 3

Singletons pattern generally refers to a single global instance. I.e. a static property in c#. Most of the problems with this is related to the "global" part, or more specifically, the combination of "global" and "mutable".
This question goes into the problems with singleton pattern in more details

So when you want to use DI for singleton behavior you must use a container, right?

No, you may still design your application with only one instance of a class, simply create it in the main method and inject it to all who needs it. This avoids most of the problems with SP, but you still have only one object. This works just the same as using a DI container, except you need to manage the creation yourself.

Also note that "singleton" lifetime with regards to DI containers means that there is one instance of a class per container, and that this instance lives at most as long as the container. This is different from SP since there is nothing "global" about this.

So at the end the container is just managin the single stuff for you, right?

No, you can still use the container to create objects with shorter lifetimes than the container. I might for example have a logging object registered as a singleton, but resolve multiple instances of a class that depends on this logger.

So DI is not something we should oppose to SP. DI with container is something I can oppose to SP.

This seem opinion based, but from my point of view they are quite opposite. SP hides dependencies, DI makes them clearer. SP makes it more difficult to replace or mock dependencies, DI makes it trivial.

So at the end why I should not use SP by myself but trust a library to do it?

As previously mentioned, you do not need a library to use DI, even if it makes it easier. I would personally trust a library used by thousands more then I trust my own code.

What is the difference between DI using container with single scope and SP?

You avoid most of the issues with SP for a start.

As an example, consider a application that connects to a database, where the database connection is in a global singleton. This might work fine, but consider if the requirements change so that it should be possible to connect to multiple databases, each with a separate window or view. SP makes such a change almost impossible since every class that uses the database must now know which database to use.

If a DI container is used, this can be almost trivial, simply create another container object in the same way you created the first one, but with a different connection string. Only the code that directly deals with loading or selecting databases need to know there are several of them. Other objects do not need to change, because in the context of the DI container they live in, there is still only one database.