For standalone non Android applications what is everyone s p

Question

For standalone non Android applications what is everyone s preferred DI library

gildor · Answer

I believe Dagger2 is still the best option if you need fast and most scalable solution

Casey Brooks · Answer

I prefer Guice been using it for years Less boilerplate and much easier to set up and being a reflection based lib makes it possible to use it for a simple plugin system Only downside is that it has long startup times but for long running applications this is easy to ignore

gildor · Answer

What kind boilerplate do you have in Dagger

gildor · Answer

You also can use Dagger for plugins using multi binding

gildor · Answer

But I agree reflection based can have some advantages but still on scale annotation processing can give significant advantages about speed and compile time checks

Casey Brooks · Answer

For boilerplate Guice has no need for Components or anything like it and the modules are a bit cleaner as well

Casey Brooks · Answer

For plugins you need to recompile the core in order to support a new module which wouldn t work in a framework setting You can take your framework a bunch of modules compiled elsewhere and still get them to build a single graph entirely at runtime perhaps through configuration files or classpath scanning to find these modules

Casey Brooks · Answer

But I totally agree the nature of reflection DI does mean you lose some performance and safety but it is by no means a deal breaker IMO

gildor · Answer

But if you have only one scope for whole application and only constructor injections you component will have one method I agree this is can be considered as boilerplate but also it s just more explicit

gildor · Answer

It depends of course I agree

Shawn · Answer

fwiw I don t use anything but constructor injection field injection is scary stuff at times lol

David Hamilton · Answer

So given the power of Kotlin s `lazy` what are the advantages of a DI library over using lazy `val`s singletons and `fun`s providers in a custom Dependencies class

gildor · Answer

Because DI has nothing related to lazy

gildor · Answer

And DI is not about singletons

gildor · Answer

lazy property for dependency creation is actually against DI rules You should provide dependencies from outside do not create them on the same class

gildor · Answer

Of course you can write Service Locator using delegate properties to request required dependencies but again this is dependency inversion but not DI

gildor · Answer

and has the main problem of service locator class has hard dependency on service locator implementation

David Hamilton · Answer

Ahhh I wasn t clear

David Hamilton · Answer

I mean create a Dependencies class with all the injectable resources as vals and inject one into the other into the lazy initialisers They re external and injectable

gildor · Answer

so every class that need any dependency now has hard dependency to Dependencies

gildor · Answer

which is also not really good solution especially on big scale

gildor · Answer

it s even worse that service locator

David Hamilton · Answer

Other way around

gildor · Answer

DI is ```class SomeClass val dep1 SomeDep1 val dep2 SomeDep2 ``` or the same with method injection which has a lot of problems especially in Kotlin with nullability

gildor · Answer

So you have inversion of control and class doesn t have any hard dependencies to any Injector ServiceLocator and so on

gildor · Answer

gt Other way around could you show an example

David Hamilton · Answer

```open class Dependencies open val serviceB ServiceB by lazy ServiceB serviceA open val serviceA ServiceA by lazy ServiceA ```

gildor · Answer

Okay where is dependency injection here

David Hamilton · Answer

Sorry more haste less speed smile

David Hamilton · Answer

Obvs ServiceA instance is lazily created when it needs to be injected into B or is used elsewhere

David Hamilton · Answer

Class can easily be overridden by subclasses to inject test dependencies

gildor · Answer

This is manual dependency injection yes

gildor · Answer

now add 10 more dependencies

gildor · Answer

and some graph of them

David Hamilton · Answer

Sure but if I compare with my Guice definitions it s hardly if any more complicated

gildor · Answer

But I agree Kotlin simplifies manual dependency injection code a lot

gildor · Answer

yes sorry just now get your point yes this may be a valid approach of course but mostly on relatively small scale

gildor · Answer

we use similar approach on one of our small projects

gildor · Answer

but looks that when this graph will grow it will be really hard to support it

David Hamilton · Answer

Yes true

gildor · Answer

gt Sure but if I compare with my Guice definitions it s hardly if any more complicated If you use constructor with ` Inject` annotation and your modules mostly just maps interfaces to implementations or even don t do this than Guice or Dagger will save a lot of boilerplate for you

David Hamilton · Answer

thinking face Maybe I missed a trick with Guice Checking

gildor · Answer

Because main boilerplate in this case will be defining new dependencies in your Dependencies class invoking constructors and passing dependencies which completely eliminated by Guice reflections or Dagger code generations

gildor · Answer

Of course DI framework adds additional configuration overhead and on small scale this overhead can be higher than saved boilerplate

gildor · Answer

but if you have relatively big graph you save a lot of code especially if you use mostly constructor injections with dependencies that exist on the same graph which is should be you preferred way to work with dependencies

David Hamilton · Answer

Ah yes I used the ` Provides` annotation in Guice which yields a Module almost identical to that in the lazy example

gildor · Answer

Yes ` Provides` significantly increase amount of code but in most cases you actually can avoid this

gildor · Answer

even for complicated cases when you need dynamic parameter as dependency it s possible to use ` AssistedInject` for this

David Hamilton · Answer

IIRC my main driver in using ` Provides` was to allow test contexts to override certain dependencies Is that possible using ` Inject`

gildor · Answer

But you can override test dependencies but you need module for that

gildor · Answer

Because you can override Inject dependency with Provides dependency

gildor · Answer

Do you need this for some integration tests

gildor · Answer

Also I m not so familiar with Guice but this is reflection so you probably can just replace it on reflection level without actual updating of graph