CDI是否可以很好地替代Spring？

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

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

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

依赖注入由两个容器处理。主要区别在于CDI以动态（即有状态）方式处理DI的事实-这意味着依赖关系在执行时得以解决。Spring的方法是静态的-这意味着在创建时将组件连接在一起。乍一看，CDI方式似乎有点不寻常，但它的优势远不止于此，它提供了更多高级选项（我是在两个高效CDI应用程序的背景下编写的）。

如果您看一下生态系统，情况就不一样了：Spring捆绑了很多jar（> 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以获得一个好的开始...

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

但是，CDI可以替代Spring的DI API。

我正在使用Apache OpenWebBeans作为CDI的实现，而MyFaces CODI作为几个项目的可移植扩展。我对此非常满意，但我没有任何问题。目前，OpenWebBeans缺乏文档方面的知识，但是如果您无法正常工作，则可以使用MyFaces提供的Maven原型来轻松生成具有所有所需依赖项的简单项目，或者在邮件列表中询问。如果您仅在应用程序上工作，并且不会被讨厌的错误所阻塞，那就太好了。我在Spring上也做了很多项目。没关系，但是如果您问我将在下一个项目中使用什么，那么明确的答案就是OpenWebBeans和CODI！与Weld相比，我更喜欢OpenWebBeans，因为OpenWebBeans非常易于采用，这很棒，因为您可以自定义更多或更少的所有内容，由官方的CDI API / SPI涵盖，并且运行时性能更好。在第一个项目结束后，我再也不会质疑CODI了，因为它非常稳定，它们具有定期发布的功能，并且大多数都带来了很棒的新功能，从而极大地提高了生产率。CODI是恕我直言，是整个CDI土地上最稳定，最多创新的地方。

回答您的问题：对我而言，CDI完全替代了Spring，但是您需要可移植的扩展来填补空白。作为标准，CDI从未打算解决所有问题，而诸如对话之类的某些部分却被设计打破了。好消息是您拥有MyFaces CODI等出色的项目。CODI解决了几乎所有这些问题。