Java 当您拥有 Spring 和 Dagger 时，为什么要使用/开发 Guice？

Why use/develop Guice, when You have Spring and Dagger?

提问by spam

To my knowledge, Dagger does generate code, while Guice and Spring rely on runtime processing, thus Dagger works faster, but requires more work on programmer side. Because of performance edge it's good for mobile (Android) development.

据我所知，Dagger 确实会生成代码，而 Guice 和 Spring 依赖于运行时处理，因此 Dagger 运行速度更快，但需要更多的程序员工作。由于性能优势，它非常适合移动 (Android) 开发。

However, when we are left with Guice and Spring, the latter has lots of integrations. What's the point of developing/using Guice, if we can use Spring Framework (that does basically same thing, but offers ex. easier database access)?

然而，当我们剩下 Guice 和 Spring 时，后者有很多集成。如果我们可以使用 Spring Framework（基本上做同样的事情，但提供更容易的数据库访问），那么开发/使用 Guice 的意义何在？

Isn't Google trying to reinvent wheel by creating their own DI tool, instead of using (and possibly contributing to) Spring Framework?

谷歌是不是试图通过创建自己的 DI 工具来重新发明轮子，而不是使用（并可能为）Spring 框架做出贡献？

I am looking for decision tree, that guides through choosing DI tool.

我正在寻找决策树，它指导您选择 DI 工具。

采纳答案by Jeff Bowman

It's important to realize that Dagger was created after Guice, by one of Guice's creators ("Crazy Bob" Lee) who had moved to Square:

重要的是要意识到 Dagger 是在 Guice 之后创建的，由 Guice 的一位创造者（“Crazy Bob”Lee）搬到了 Square：

• Spring was originally released in October 2002.
• Google originally released Guice publicly in March 2007.
• JSR-330formalized javax.injectannotations in October 2009, with heavy input from Google (Bob Lee), Spring, and other industry players.
• Square originally released Dagger 1 publicly in May 2013.
• Google originally released Dagger 2 publicly in April 2015.
• Square marked Dagger 1 as deprecated 10 days before this question was asked, on September 15, 2016.

• Spring 最初于2002年10 月发布。
• Google 最初于2007年3 月公开发布了 Guice 。
• JSR-330javax.inject于2009年10 月正式化了注释，并得到了 Google（Bob Lee）、Spring 和其他行业参与者的大量投入。
• Square 最初于2013年5 月公开发布了 Dagger 1 。
• 谷歌最初于2015年4 月公开发布了 Dagger 2 。
• Square 在2016年9 月 15 日提出此问题前 10 天将 Dagger 1 标记为已弃用。

In that sense, the continued curation of Guice isn't "reinventing the wheel" so much as maintenance on a long-running and widely-consumed software package that thoroughly predates any version of Dagger. You might consider Dagger to be a spiritual successor to Guice, but one that only offers an optimized subsetof Guice's functionality.

从这个意义上说，Guice 的持续管理与其说是“重新发明轮子”，不如说是维护一个长期运行且广泛使用的软件包，该软件包完全早于 Dagger 的任何版本。您可能认为 Dagger 是 Guice 的精神继承者，但它仅提供Guice 功能的优化子集。

To list and amend to the differences you have above:

列出并修改上述差异：

• Spring is a relatively-heavyweight framework with a lot of integrations, an XML configuration language, and runtime/reflective bindings. Applications already using Spring can use Spring's dependency injection framework with very little extra work.
• Guice is a relatively-lightweight framework with fewer integrations, Java instance configuration, and runtime/reflective bindings. With the use of Java bindings, you get compile-time type checking and IDE autocomplete integration.
• Dagger is a very lightweight framework with very few integrations, Java interface/annotation configuration, and compile-time code-generated bindings. The code generation aspect makes Dagger very performant overall and particularly in resource-limited and mobile environments. (Android's VMs differ from server JREs in ways that make reflection especially slow, so Dagger is especially useful here.)
• All three of the above frameworks support JSR-330, so a well-crafted library or application can be mostly agnostic to the DI container used.

• Spring 是一个相对重量级的框架，具有大量集成、XML 配置语言和运行时/反射绑定。已经使用 Spring 的应用程序只需很少的额外工作就可以使用 Spring 的依赖注入框架。
• Guice 是一个相对轻量级的框架，具有较少的集成、Java 实例配置和运行时/反射绑定。通过使用 Java 绑定，您可以获得编译时类型检查和 IDE 自动完成集成。
• Dagger 是一个非常轻量级的框架，具有很少的集成、Java 接口/注释配置和编译时代码生成绑定。代码生成方面使 Dagger 整体性能非常好，尤其是在资源有限和移动环境中。（Android 的 VM 与服务器 JRE 的不同之处在于反射特别慢，因此 Dagger 在这里特别有用。）
• 以上三个框架都支持 JSR-330，因此精心设计的库或应用程序可能与所使用的 DI 容器无关。

Beyond that, keep an eye out for maintenance/deprecation patterns and policies among any framework you use. Based on your team's knowledge and experience, your need for reflection or runtime configuration, and your need for integrations and runtime performance, you'll probably see one of the above stand out. That said, there are also other frameworks out there, so keep an eye open for new options and forks of the above as well.

除此之外，请留意您使用的任何框架中的维护/弃用模式和策略。根据您团队的知识和经验、您对反射或运行时配置的需求，以及您对集成和运行时性能的需求，您可能会看到上述其中一项脱颖而出。也就是说，还有其他框架，所以请留意上述的新选项和分支。