谷歌指南 vs. JSR-299 CDI / Weld

java dependency-injection aop cdi jboss-weld

2022-08-31 15:39:31

Weld，JSR-299 Contexts and Dependency Injection参考实现，认为自己是Spring和Guice的继承者。

CDI受到许多现有Java框架的影响，包括Seam，Guice和Spring。然而，CDI有自己非常独特的特征：比Seam更多的类型安全，比Spring更有状态，更少以XML为中心，比Guice更具有Web和企业应用程序的能力。但是，如果没有上述框架的灵感以及JSR-299专家组（EG）的大量合作和辛勤工作，就不可能是其中任何一个。

http://docs.jboss.org/weld/reference/latest/en-US/html/1.html

与Guice相比，是什么让Weld更适合企业应用？与Guice相比，有什么优点或缺点吗？您如何看待Guice AOP与Weld拦截器相比？性能如何？

我的选择

最后，我决定使用Guice，因为我喜欢干净的编程模型，除了默认情况下@Inject之外，它几乎没有注释。与使用 CDI 相比，使用 Guice 的外部库要容易得多。AOP对于Guice来说也非常简单。

答案 1

在尝试回答您的问题之前，让我补充一条重要信息：JSR 330 （）已由 Guice 和 Spring 项目标准化（2009 年 5 月发布），并在 JSR 299 中重用。这涵盖了声明注入点的基本DI机制。@Inject

现在，回到问题 - 免责声明，我对Spring的经验远远超过Guice。

Weld 的企业能力

替代配置机制在 JSR-299 中具有非常干净的设计，并允许在 Java 代码之外使用配置机制（）。beans.xml
事件是一个非常强大的东西，非常适合JMS。我刚刚为Guice找到了一个事件总线，但我不能说它是如何比较的。
可移植扩展是一种SPI，可用于与现有技术集成或以干净的方式包装遗留代码。

优点/缺点

注意：我稍后会尝试在这里添加一些项目，但是这个答案已经比我预期的要长，对不起。

焊缝/CDI
- 标准化：如果某些东西是标准化的，并且有一个很好的实现，很多人都会使用它。示例：Weld 中的内置示波器提供了比 Guice 或 Spring 更多的示波器。所有这些都可以扩展，但是如果大型社区使用标准范围，则应用程序框架将依赖于标准范围。
- 容器支持：这与上一项类似，但采用的主要参数。主要的开源应用服务器，如Glassfish和JBoss 6提供CDI支持（见这里）。
圭斯/弹簧
- 实际应用：大多数现有应用程序已经使用 Guice/Spring。Spring/Guice始终以标准为基础，并在没有标准存在或无法使用的情况下提供新功能。如果您遵循相应的最佳实践，该框架将帮助您使应用程序基于标准且整洁。

AOP 和拦截器

这是一个讨论非常激烈的话题，我不能偏袒任何一个。这两种机制都非常强大，但至少需要对应用程序的体系结构有最低限度的了解。另请查看装饰器和以前引用的事件。最好使用正确的工具，但不要忘记，如果开发人员必须使用这些机制之一，如果他/她理解这个概念，这是一件好事。

性能

不幸的是，我还不能研究这个问题，但是我试图遵循一些规则，特别是当使用一个框架时，它为你提供了很多功能，而你没有注意到它：

只要有可能，在运行时，最好选择单个连接步骤而不是多个查找。
如果可能，请在应用程序初始化时执行所有连接。
任何拦截步骤或 AOP 代理都会向堆栈添加一些方法调用。

答案 2

CDI（Weld）尚未被广泛使用，因此很难进行比较。几点：

CDI 在设计时考虑了 EJB3、JSF 和其他 JavaEE 标准的集成。CDI具有所谓的可移植扩展，允许第三方库与CDI实现的生命周期和内部功能集成
CDI在设计时考虑了所有可能的极端情况，因此它可能涵盖了您需要的所有内容。Spring，Guice和Seam进化到这样的状态，而CDI则利用了这三者的经验。
在我看来，CDI拦截器将无法满足Spring AOP满足的所有要求。也许Guice AOP也是如此。不能使用 AspectJ 语法定义侦听器。
缺少xml定义既是优点也是缺点，有些人（在某些情况下是正确的）更喜欢xml配置。
如果谨慎使用，限定符注释的扩展使用（在我看来）会产生一些大混乱。