Use a dependency injection framework in the Java server

[adiherzog]

We could start using a DI framework like Google Guice on the server side. It's quite low priority, therefore I assign it to "Prio 2".

[forkch]

yes I would recommend Guice as well. I use Dagger on Android which is heavily influenced by Guice

[forkch]

Let's wait with this until Dagger 2 comes out. Like Dagger it validates the dependency graph at compiletime as opposed to guice (and Spring) at runtime, but has a much simpler API and NO reflection magic :-)

[forkch]

See DAGGER 2 - A New Type of dependency injection: http://youtu.be/oK_XtfXPkqw

[danielsuter]

It needs it's own precompiler. Does this work well with eclipse? The current version also has some limitations (no injection to private fields, @Inject is needed everywhere).

See also http://dig.floatingsun.net/dagger-vs-guice/.

[forkch]

It's not an own precompiler, it uses the annotation processor mechanism available in javac. You simply have to include the compiler jar in the annotation processing settings. And in the gradle build it works anyway. By the way IntelliJ is much better than eclipse :-)

I personally consider field injection bad practice. Constructor injection leads to much more testable code without having to inject the fields of your testee by some reflection magic but instead simply invoke the constructor with the needed collaborators (real objects, fakes, mocks or whatever).

[forkch]

and google will use this in future instead of guice, so it should be ok for us ;-)

[mi-we]

I discussed recently with @adhierzog about the use of dependency injection. I think in regard of future functionality it might really be a good idea to have this. Basically I would have used CDI because it is already there but I also researched a bit about Dagger and it looks quite interesting.

[bruderol]

I personally think that we can close this topic now that we have spring in the backend and can use it where appropriate. But also I dont see big need to do much more DI than currently in the backend. @adiherzog @mi-we do you agree to close this?

[mi-we]

@bruderol Fine for me