Simple Injector VS Guice

When I was building application with .NET Framework I always used libraries like Autofac and SimpleInjector for dependency injection. I really liked to create modules (Packages in SimpleInjector) to achieve higher cohesion and lower coupling in my class libraries. I made a module for every class library in which all dependencies inside of that class library were registered. Why should my web application (for example) know if MyBeautifulService in MyBeautifulClassLibrary should be transient or singleton?

My favorite DI container is LightInject. Very fast and has all the features that I need. Other good DI containers are Grace and SimpleInjector, IMO.

> Dependency injection has always been such a bad name for the concept. It is just passing dependencys as arguments.

No.

Dependency Injection means using tooling to "inject" the dependency, instead of passing an explicit argument.

https://github.com/google/guice

> Think of Guice's `@Inject` as the new `new`.

Like many architecutral design patterns, toy examples don't illustrate the concept well. It's used for doing things like switching a large service-based system from using external databases and remote services for production, to in-memory everything for testing.

“There are many advantages to using dependency injection, but doing so manually often leads to a large amount of boilerplate code to be written. Guice is a framework that makes it possible to write code that uses dependency injection without the hassle of writing much of that boilerplate code”

This is a common misconception. Guice’s docs delineate between dependency injection as a pattern and Guice as a framework that supports that pattern.

https://github.com/google/guice/wiki

Usually each context has a different scope and lifetime associated with it. Here, it sounds like there are two distinct scopes: server and request (cf. how Guice models scopes: https://github.com/google/guice/wiki/Scopes). It is rarely sensible to merge the scopes or contexts together. If we think about a context, it contains several things:

using libraries from java world, such as Guice;

As said in the title, we will focus on the dependency inversion principle and one of its application : dependency injection. For production-ready applications, it would be better to rely on a framework and not implement its own container. For it, the java ecosystem have 3 frameworks available : Spring, Guice and Dagger.

And it doesn't really matter whether you have created circular reference structure of whether you have messed up your binding and now objects which was supposed to disappear after one request is only doing that when all database connections are quiescent (which happens easily in testing, but may not happen for days in production).

https://github.com/google/guice/issues/1536

... with guice or Spring Boot,

The following section is an example of injecting our service using Guice, a dependency injection framework for Java made by Google. The concept is to reference bindings of every component you can inject in your program, so that the library can generate a class of any type, automatically.