3 ms·
Go for Guice if you just want DI. You won't regret it. But always remember, all "auto" stuff might mislead you. For example, you need somebody to start things f
by rakila 13y ago
Go for Guice if you just want DI. You won't regret it. But always remember, all "auto" stuff might mislead you. For example, you need somebody to start things for you, so in Spring, the Servlet container will invoke the Spring Servlet, which will take things up from there. That's the catch, it's not magic, right? So with Guice, you need to figure out who will so that "auto" for you. Btw, if you're just building a small library, Guice is definitely the DI choice. HTH.
- kilemensi 13y agoFrom the article, the author clearly states he has issues with the DI-driven design in general; Spring just happened to be the DI framework he was using at the time. Guice or any other framework for that matter would not have made any difference. Money quotes: >>>> In the end, creating a coherent, small system is to me of much higher value than to create one that is decoupled just for the sake of decoupling. Coherence and decoupling are opposing forces and I side with coherence. >>>> So reuse and decoupling are opposing forces. I find myself siding with decoupling.
- ivan_gammel 13y agoIf it's a library, not an app, it's better not to rely on DI at all, leaving the choice of container to user. As a library designer you can implement reasonable manual auto-wiring of default configuration. For small applications (both server-side and client-side) Spring 4 is as easy to use as Guice.
- moondowner 13y agoThere is also Dagger (developed by Square) http://square.github.io/dagger/ http://square.github.io/dagger/ Pretty similar to Guice, but faster.
- MrBuddyCasino 13y agoHa, Bob doing another DI framework? Is it any good?