CDI是Spring的一个很好的替代品吗？

Question

我们计划从头开始编写Web应用程序，已决定使用符合Java EE 6标准的最新版Glassfish，因此我们正在分析是否可以使用CDI而不是Spring。

我们可以说CDI可以替代Spring吗？

Answer 1

CDI代表“上下文和依赖注入”，而Spring是一个围绕依赖注入容器的完整生态系统。要比较两者，您必须区分比较。

依赖注入由两个容器处理。主要区别在于CDI以动态（又名：有状态）方式处理DI - 这意味着依赖关系在执行时解析。 Spring的方法是 static - 这意味着组件在创建时连接在一起。虽然CDI方式在第一眼就看起来有点不同寻常，但它更优越，提供了更多更高级的选择（我正在以两个高效的CDI应用程序为背景来编写）。

如果你看一下生态系统，情况会有所不同：Spring与很多罐子（> 150）捆绑在一起，而CDI本身很小。典型的CDI用法将位于Java EE 6应用程序服务器内部，但您可以轻松地使其在servlet引擎甚至Java SE中运行。这意味着使用CDI不会假设使用Hibernate，JPA，EJB或其他任何东西 - 这取决于你。

如果您需要更多功能，CDI会提供可移植扩展的概念（这本身就是值得的API）。存在独立的扩展模块，如Apache CODI和Seam 3，涵盖安全，邮件，报告等主题。

总结一下：CDI与Spring生态系统的“替代”完全不同，它相当于对Spring的依赖注入机制的改进。它是Java EE 6的一部分，所以如果您使用的是带有Java EE 6的GlasFish，那么您一定要选择CDI。在我看来，你的问题是：我可以用Java EE 6替换Spring吗？我想我的回答非常明显; - ）

看看Weld以获得良好的开端......

Answer 2

Spring不仅仅是一个依赖注入容器。它还有AOP工具，用于JPA，SQL等的模板甚至更多。

然而，CDI可以替代Spring的DI API。

Answer 3

我使用Apache OpenWebBeans作为CDI实现，MyFaces CODI作为多个项目的可移植扩展。我很满意它，我没有遇到任何问题。 OpenWebBeans目前在文档方面缺乏一点，但如果你无法使用它，可以很容易地使用MyFaces提供的Maven Archetypes来生成包含所有必需依赖项的简单项目，或者在邮件列表中询问。如果您只是处理您的应用程序并且您没有被令人讨厌的错误阻止，那就太棒了。我还用Spring做了很多项目。没关系，但是如果你问我将用于下一个项目的是什么，那么明确的答案就是OpenWebBeans和CODI！我更喜欢OpenWebBeans而不是Weld，因为OpenWebBeans非常适用，因为您可以自定义或多或少地定制官方CDI API / SPI未涵盖的所有内容，并且运行时性能更好。在第一个项目之后，我再也不会质疑CODI，因为它非常稳定，它们定期发布，大多数都带来了很多新功能，可以大大提高生产力。 CODI是IMHO最稳定的地方，大多数创新来自整个CDI土地。

回答你的问题： 对我来说，CDI完全取代了Spring，但是你需要便携式扩展来填补空白。作为标准的CDI从未打算解决所有问题，而某些部分如会话被设计破坏。好消息是你有像MyFaces CODI这样的伟大项目。 CODI几乎解决了所有这些问题。