CDI 是 Spring 的良好替代品吗？

Is CDI a good replacement of Spring?

提问by prassee

We are planning to write a web application from the scratch, it has been decided to go with the latest edition of Glassfish which complies to Java EE 6 standard, therefore we are analyzing if CDI can be use instead of Spring.

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

Can we say that CDI could be a replacement for Spring?

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

回答by jan groth

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.

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

Dependency injectionis 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).

依赖注入由两个容器处理。主要区别在于 CDI 以动态（又名：有状态）方式处理 DI - 这意味着在执行时解决依赖关系。Spring 的方法是静态的——这意味着组件在创建时连接在一起。虽然 CDI 方式乍一看似乎有点不寻常，但它要优越得多，并且提供了更多和高级的选项（我是在两个高效 CDI 应用程序的背景下写这篇文章的）。

If you look at the ecosystem, the situation is different: Spring comes bundled with a lot ofjars (>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.

如果您查看生态系统，情况就不同了：Spring 捆绑了很多jar（>150 个），而 CDI 本身非常小。典型的 CDI 用法将在 Java EE 6 应用程序服务器内部，但您可以轻松地使其在 servlet 引擎甚至 Java SE 中工作。这意味着使用 CDI 不假设使用 Hibernate、JPA、EJB 或其他任何东西 - 这取决于您。

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.

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

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 ;-)

总结一下：CDI 完全不是 Spring 生态系统的“替代品”，而是对 Spring 依赖注入机制的改进。它是 Java EE 6 的一部分，因此如果您使用的是带有 Java EE 6 的 GlasFish，那么您绝对应该选择 CDI。在我看来，您的问题是：我可以用 Java EE 6 替换 Spring 吗？我想我的答案很明显;-)

Have a look at Weldto get a good start...

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

回答by Behrang Saeedzadeh

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.

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

However CDI can be used as a replacement for Spring's DI API.

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

回答by Dar Whi

I'm using Apache OpenWebBeansas 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.

我正在使用Apache OpenWebBeans作为 CDI 实现和 MyFaces CODI 作为多个项目的可移植扩展。我对它很满意，我没有遇到任何问题。OpenWebBeans 目前缺乏一些文档，但是如果您不能让某些东西工作，那么使用 MyFaces 提供的 Maven Archetypes 来生成具有所有需要的依赖项的简单项目是非常容易的，或者您可以在邮件列表中询问。如果你只是在你的应用程序上工作并且你没有被讨厌的错误阻止，那就太好了。我也用 Spring 做了很多项目。没关系，但是如果您问我将在下一个项目中使用什么，那么明确的答案是 OpenWebBeans 和 CODI！我更喜欢 OpenWebBeans 而不是 Weld，因为 OpenWebBeans 非常易于采用，这很棒，因为您可以或多或少地自定义所有不 t 被官方 CDI API/SPI 覆盖，运行时性能更好。在第一个项目之后，我再也不会质疑 CODI，因为它非常稳定，它们定期发布，其中大多数都带来了很棒的新功能，大大提高了生产力。恕我直言，CODI 是整个 CDI 领域中最稳定、最多创新的地方。

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.

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