如果您需要更多功能，CDI 带有可移植扩展的概念（这本身就使得 API 有价值）。存在 Apache CODI 和 Seam 3 等独立扩展模块，涵盖安全、邮件、报告等主题。
总结一下：CDI 并不是 Spring 生态系统的“替代品”，而是对 Spring 依赖注入机制的改进。它是 Java EE 6 的一部分，因此如果您使用的是 Java EE 6 的 GlasFish，那么您绝对应该选择 CDI。在我看来，您的问题是：我可以用 Java EE 6 替换 Spring 吗？我想我的答案很明显;-)
Update 2021: It's been 10 years since I answered the original question, and I'm still getting the occasional upvote. Can I just ask future readers to take my response as what it is: A reflection of the Java Enterprise landscape in 2011.
CDI stands for "context and dependency injection", while Spring is a complete ecosystem around a dependency injection container. To compare both, you have to differentiate the comparison.
Dependency injection is handled by both containers. The main difference is the fact that CDI handles DI in a dynamic (aka: stateful) way - this means that dependencies are resolved at execution time. Spring's approach is static - this means that components are wired together at creation time. While the CDI-way might seem a bit unusual at a first glimpse, it's far superior and offers way more and advanced options (I'm writing this with the background of two productive CDI apps).
If you look at the ecosystem, the situation is different: Spring comes bundled with a lot of jars (>150), while CDI is pretty small by itself. A typical CDI-usage would be inside of a Java EE 6 application server, but you can easily make it work in a servlet engine or even Java SE. This means that using CDI makes no assumption about using Hibernate, JPA, EJB or whatever - that's up to you.
If you need more functionality, CDI comes with the concept of portable extensions (which by itself makes the API worthwile). Independent extension modules like Apache CODI and Seam 3 exist and cover topics like security, mailing, reporting and more.
To summarize: CDI is nothing like a "replacement" for the Spring ecosystem, it's rather an improvement over Spring's dependency injection mechanism. It's part of Java EE 6, so if you are on a GlasFish with Java EE 6, you should definitely go for CDI. In my eyes your question is rather: Can I replace Spring with Java EE 6? I guess my answer is pretty obvious ;-)
I'm using Apache OpenWebBeans as CDI implementation and MyFaces CODI as portable extension for several projects. I'm very happy with it and I had no problems with it. OpenWebBeans currently lacks a bit in view of documentation but if you can't get something to work it's pretty easy to use the Maven Archetypes provided by MyFaces to generate simple projects with all the needed dependencies or you ask on the mailing list. It's so great if you just work on your Application and you aren't blocked by nasty bugs. I also did a lot of projects with Spring. It's ok, but if you ask what I would use for the next project the clear answer is OpenWebBeans and CODI! I prefer OpenWebBeans over Weld because OpenWebBeans is very adoptable that's great because you can customize more or less everything which isn't covered by the official CDI API/SPI and the runtimeperformance is better. And after the first project I would never question again CODI because it's very stable, they have regular releases and most of them brought great new features which improve the productivity a lot. CODI is IMHO the place which is most stable and were most innovations come from in the whole CDI land.
To answer your question: For me CDI completely replaced Spring, but you need portable extensions which fill the gaps. CDI as standard never intended to solve everything and some parts like the conversations are broken by design. The good news is that you have great projects like MyFaces CODI. CODI fixes almost all those issues.
发布评论
评论（3）
2021 年更新：自从我回答最初的问题以来已经过去了 10 年，但我仍然偶尔得到点赞。我能否请未来的读者接受我的回答：2011 年 Java 企业版图的反映。
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< /a> 有个好的开始...
Update 2021: It's been 10 years since I answered the original question, and I'm still getting the occasional upvote. Can I just ask future readers to take my response as what it is: A reflection of the Java Enterprise landscape in 2011.
CDI stands for "context and dependency injection", while Spring is a complete ecosystem around a dependency injection container. To compare both, you have to differentiate the comparison.
Dependency injection is handled by both containers. The main difference is the fact that CDI handles DI in a dynamic (aka: stateful) way - this means that dependencies are resolved at execution time. Spring's approach is static - this means that components are wired together at creation time. While the CDI-way might seem a bit unusual at a first glimpse, it's far superior and offers way more and advanced options (I'm writing this with the background of two productive CDI apps).
If you look at the ecosystem, the situation is different: Spring comes bundled with a lot of jars (>150), while CDI is pretty small by itself. A typical CDI-usage would be inside of a Java EE 6 application server, but you can easily make it work in a servlet engine or even Java SE. This means that using CDI makes no assumption about using Hibernate, JPA, EJB or whatever - that's up to you.
If you need more functionality, CDI comes with the concept of portable extensions (which by itself makes the API worthwile). Independent extension modules like Apache CODI and Seam 3 exist and cover topics like security, mailing, reporting and more.
To summarize: CDI is nothing like a "replacement" for the Spring ecosystem, it's rather an improvement over Spring's dependency injection mechanism. It's part of Java EE 6, so if you are on a GlasFish with Java EE 6, you should definitely go for CDI. In my eyes your question is rather: Can I replace Spring with Java EE 6? I guess my answer is pretty obvious ;-)
Have a look at Weld to get a good start...
Spring 不仅仅是一个依赖注入容器。它还具有用于 AOP 的工具、用于 JPA、SQL 等的模板，甚至更多。
然而，CDI 可以用作 Spring 的 DI API 的替代品。
Spring is more than just a dependency injection container. It also has tools for AOP, templates for use with JPA, SQL, etc. and even more.
However CDI can be used as a replacement for Spring's DI API.
我使用 Apache OpenWebBeans 作为 CDI 实现，并使用 MyFaces CODI 作为多个项目的可移植扩展。我对此非常满意，并且没有遇到任何问题。 OpenWebBeans 目前缺乏一些文档，但如果您无法让某些东西起作用，那么可以很容易地使用 MyFaces 提供的 Maven Archetypes 来生成具有所有所需依赖项的简单项目，或者您在邮件列表上询问。如果您只专注于您的应用程序并且没有被讨厌的错误阻止，那就太棒了。我还用 Spring 做了很多项目。没关系，但如果你问我下一个项目会使用什么，明确的答案是 OpenWebBeans 和 CODI！与 Weld 相比，我更喜欢 OpenWebBeans，因为 OpenWebBeans 的采用性非常好，这很棒，因为您可以或多或少地自定义官方 CDI API/SPI 未涵盖的所有内容，并且运行时性能更好。在第一个项目之后，我再也不会质疑 CODI，因为它非常稳定，他们有定期发布，其中大多数都带来了很棒的新功能，大大提高了生产力。恕我直言，CODI 是整个 CDI 土地上最稳定、最多创新的地方。
回答你的问题：
对我来说，CDI 完全取代了 Spring，但您需要可移植的扩展来填补空白。 CDI 作为标准从来没有打算解决所有问题，并且某些部分（例如对话）在设计上被破坏了。好消息是您有像 MyFaces CODI 这样的伟大项目。 CODI 几乎解决了所有这些问题。
I'm using Apache OpenWebBeans as CDI implementation and MyFaces CODI as portable extension for several projects. I'm very happy with it and I had no problems with it. OpenWebBeans currently lacks a bit in view of documentation but if you can't get something to work it's pretty easy to use the Maven Archetypes provided by MyFaces to generate simple projects with all the needed dependencies or you ask on the mailing list. It's so great if you just work on your Application and you aren't blocked by nasty bugs. I also did a lot of projects with Spring. It's ok, but if you ask what I would use for the next project the clear answer is OpenWebBeans and CODI! I prefer OpenWebBeans over Weld because OpenWebBeans is very adoptable that's great because you can customize more or less everything which isn't covered by the official CDI API/SPI and the runtimeperformance is better. And after the first project I would never question again CODI because it's very stable, they have regular releases and most of them brought great new features which improve the productivity a lot. CODI is IMHO the place which is most stable and were most innovations come from in the whole CDI land.
To answer your question:
For me CDI completely replaced Spring, but you need portable extensions which fill the gaps. CDI as standard never intended to solve everything and some parts like the conversations are broken by design. The good news is that you have great projects like MyFaces CODI. CODI fixes almost all those issues.