Java 服务器端应用程序的静态依赖注入解决方案？答案

【问题标题】：Static dependency Injection solution for Java Server Side applications?Java 服务器端应用程序的静态依赖注入解决方案？
【发布时间】：2019-11-05 10:54:13
【问题描述】：

JavaEE 提供 CDI（上下文和依赖注入），Spring 提供依赖注入。但是，两者都会在部署（服务器启动时）引发有关重复或缺少依赖项的问题和异常。

是否有像 Dagger（用于 android）这样的依赖注入解决方案，用于服务器端应用程序，提供全静态编译时依赖项分析/解决，并通知开发人员问题和错误。

【问题讨论】：

看看Qwarkus
Quarkus 实际上，以及它的类似 CDI 的依赖注入库 ArC（还不是一个独立的项目）。
您所说的对依赖关系的抱怨非常模糊，很难说那里有什么问题。否则，CDI 可能会完成您所追求的大部分工作，除了它在编译时而不是在引导时执行，因为扩展和其他可能会在启动时影响注入模型的事情。但是，它确实会为您提供部署错误，通知开发人员哪些注入不满意/不明确等等。 Quarkus 使用 Arc 和“部分 CDI 实现”，可能更接近您描述的功能，但与 ee 是（某种）不同的方法。
恕我直言，如果您丢弃 ComponentScan 或任何扫描巫毒，并使用“java config”又名“composition root”，您可以在其中“编码”您的 DI（无论是使用 spring-di 还是 cdi），你会少很多戏剧性。我将“ComponentScan”称为 DI 的“Waldo 在哪里”方法，因为当它不起作用时，您会花费数小时追查 Waldo。 SpringDI "java config" 有很好的文档记录。这是一个 CDI 示例。 stackoverflow.com/questions/58544079/… 这里是一个关于组合根的想法的链接（简而言之，一个单一的地方来组合）
..组合依赖图：freecontent.manning.com/…

标签： java dependency-injection cdi dagger

【解决方案1】：

Dagger 不是 Android 专用的，它是一个通用 Java 库，与 Guava 一样，可以随意在服务器端使用它，以及 EE api。

您可能会争辩说，与 Spring 或 Weld 之类的相比，Dagger 更像是一种“通用 Java”解决方案，因为它使用语言的核心机制，而不是运行时提供的相当复杂的机制。这正是它在 Android 或 GWT 等平台上获得巨大成功的原因。

【讨论】：