View the Project on GitHub DivineInject


Why did we create DivineInject? Because dependency injection is important - but done wrong it can do more harm than good. DivineInject is opinionated about the right way to use dependency injection:

Constructor Injection

Setter and method injection are much harder to get right - so DivineInject simply doesn't support them. If you can't implement your dependencies as constructor arguments, then maybe you should refactor the dependency so you can.

Singleton Dependencies

Dependencies are external to your application. Things like users and sessions are domain concepts in your domain, not in the domain of dependency injectors. All dependency injection frameworks get wrapped up in different scopes, which makes the frameworks harder to use. Divine Inject simply doesn't support them — if you need something user-scoped or session-scoped, then implement the logic yourself. It isn't hard, and if you ever want to understand the lifecycle of your objects it's in your code, not mine — which will make reasoning about your code or debugging it a million times easier.

Rich Domain Objects

DivineInject borrows an idea from Google Guice - with Guice it is called "assisted injection", in DivineInject we call it generated factory injection. The idea is the same — providing a simple way to create objects with constructors which accept runtime arguments as well as dependencies to inject. This allows you to create rich, stateful domain objects which also have dependencies.

Find out more about these ideas in the detailed getting started guide.