是否有任何简单的用dagger2替换Guice中的DI实现

Question

我非常喜欢dagger2，并希望在我的新项目中使用它。唯一的问题是使用dagger2，我们仍然需要编写一些样板代码并且缺少对CDI的支持 由于Google正在开发和维护dagger2并将其用于Android开发，我想知道他们是否考虑用dagger2替换Guice中的DI实现，这是我的第一个问题。
如果他们是，那么我可以开始使用guice期待随着未来的更新，我会得到匕首的好处。
但如果不是，有没有办法可以在同一个项目中使用两者，而guice可以限制为CDI。

Answer 1

我不是匕首专家，但我会尽力回答你的问题......（我希望能做得好）

  

我想知道他们是否考虑用dagger2替换Guice中的DI实现，

不。没有充分的理由去做。 Dagger和Guice提出了完全不同的依赖注入概念方法。前者使用代码生成，后者使用运行时反射。

  

（...）有没有一种方法可以在同一个项目中使用两者，其中guice可以限制为CDI？

我不认为在同一个项目中混合CDI，Dagger和Guice是个好主意。事实上，CDI只是一个规范，而不是像Weld或OpenWebBeans这样的实际实现 - 所以我想你想说“DI”？。
无论如何：dagger-adapter extension允许使用带有Guice的Dagger2模块（使用DaggerAdapter），如果你真的想要将Dagger与Guice 4混合使用。

顺便说一下，我想让你知道Dagger是什么以及它永远不会是什么。以下是Christian Gruber（曾为Dagger工作）关于此主题的引用：

  与Dagger相比，Guice 将始终具有功能的超集，尽管我们确实在服务器和独立的Java应用程序中使用Dagger。但是Dagger并没有像Guice那样在周围的“脚手架”代码（servlet支持等）方面进化，并且不会有相当长的一段时间。此外，一些团队将需要或想要一些永远不会进入Dagger的高级Guice功能。

您可能会问这些“高级功能”是什么？它是例如AOP支持，如拦截方法，对许多开发人员来说可能至关重要。

您可以阅读可用的here整个讨论（2014年2月）。

Answer 2

作为Google的Java应用程序框架开发人员，我可以向您保证，Google已经使用Guice和Dagger构建了大型重要项目，并且在可预见的将来，这两个DI系统将继续使用和开发。

我的个人想法（这不是Google的官方计划或声明）是随着时间的推移，我们将在Dagger之上构建两个更强大的抽象（可能在附加框架和/或库中）因此，Dagger继续适用于越来越多的应用程序，以及围绕Guice的更强大的工具，使Guice开发人员的体验变得越来越与Dagger开发人员的体验相媲美，至少对于正在做＆＃34;正常＆＃34;的Guice应用程序的子集的东西。

Dagger和Guice都是有用的工具，每个工具都有不同的权衡取舍和不同的目标受众。在同一个项目中使用两者都应该是可能的，尽管这并不是理想的解决方案，因为那样你就无法充分利用其中任何一个的优势。但更好的互操作性是一个目标，Guice和Dagger团队定期就如何标准化和协调工作进行沟通。

Answer 3

在Guice和Java 11出现问题之后，偶然发现了这一点。由于我们无论如何都很少使用guice，因此我打算暂时将其淘汰，而使用dagger。 Guice给了我一个巨大的基于asm的复杂异常，该异常被掩埋了，很难读懂RCA，而且框架显然没有解决。我也经过逐步完成guice代码的尝试，试图在一周左右的时间里弄清楚这一点，发现至少对于我的用例而言，“脚手架”太多了，这使我普遍质疑DI框架的优点。 Dagger2至少在编译时运行。