简介（DI / CDI基础）

首先，我认为对此会有一些困惑，但事实是，它们是相同的–不同之处在于用法及其用途。

DI（依赖注入）是通用术语–该功能基本上是在任何应用程序上进行Bean发现和Bean连接过程的功能。 它不仅可以在应用程序中使用它，还可以在单​​元测试和模拟中使用它。 当然，那里有很多DI框架，包括：Guice，Seam，Spring（Seam和Spring扩展了DI方案，并建立了自己的框架），EJB 3.x和CDI本身。

另一方面，CDI结合了所有这些技术，并向组件引入了生命周期–这使得DI技术得以统一，从而使新功能的开发变得直截了当且可行。 您可以将Seams生命周期映射与以JPA作为其持久层的Spring MVC结合在一起-这些技术都是单独创建的，但都与CDI结合使用，应用程序开发人员可以将它们结合在一起以创建和开发JEE应用程序。

我将需要分解主题，因为我肯定会在这里用单词和字母让每个人感到无聊，所以：

1. DI / CDI基础
2. 基本注射
3. 资格赛，范围
4. DI / CDI高级

我将为每个人创建单独的帖子！

让我们开始！

SPI（服务编程接口）

它还具有所谓的SPI-显然是与API一起提供的功能集，但完全具有不同的用途。

• API是您为实现目标而调用并使用的类/接口/方法/…的描述。
• SPI是您为实现目标而扩展和实现的类/接口/方法/…的描述。

使用SPI，您实际上可以扩展JEE6以创建自己的不同框架，从而展示可移植性和可扩展性。 （ 但我稍后会介绍 ）。

为什么选择CEE for JEE6？

CDI已经出现在JEE5（J2EE）中，并取得了巨大的成功。 它的方法使很多新开发受益，最终简化了整个开发过程。 在JEE6中改进CDI的几个原因。

• JEE5确实支持资源注入，但是它仍然缺乏通用的依赖关系–它仅支持@ EJB，@ PersistenceContext，@ PersistenceUnit，@ Resources）–当然，除了Spring引入了用于管理bean生命周期的不同注释外
• 非基于类型的注入（弱）–字符串名称和XML注入确实很脆弱。 改进基于类型的注入通常可以实现更好的工具。

术语

CDI –上下文和依赖注入

焊接

• JSR 299参考实现–参考实现是用于扩展JSR特定实现的SPI。
• 为Servlet容器提供扩展的CDI支持。
• 扩展编写器的CDI增强功能。
• CDI和Java EE的Maven原型（我喜欢maven！）。

CDI主题：松耦合和强类型

松散耦合仅表示对象与使用或当前使用的对象在松散地独立。 CDI引入了用于解耦的新功能，例如限定符 ，增强了拦截器 ， 修饰器 ，消息生成器 ， 使用者及其底层事件机制。 将深入探讨有关CDI高级主题的每个示例。

强大的输入 -只是意味着通过让容器创建特定的名称并将其映射到对象来严格声明bean。 这样就不需要对字符串进行基于字符串的命名，几乎不需要铸造，因为铸造是由容器完成的（利用限定符）。

豆（什么？）

从技术上讲，您拥有多种形式的Bean：JSF Bean，EJB Bean，Spring，Seam，Guice CDI，实体Bean等，但最终，Bean只是具有特殊定义的POJO（由Managed Bean 1.0定义） – Java EE6中制定的规范。 这意味着任何POJO都可以是任何类型的bean，只要它符合规范标准即可–从而进一步简化了声明和开发过程。 容器负责管理POJO，并通过提供/引入常见的基本服务来增加对它的支持，例如：

• 生命周期管理（@ PostConstruct，@ PreDestory）
• 注入资源（@Resource）
• 拦截器（@ Interceptors，@ ArounInvoke）

@javax.annotation.ManagedBean
public class MyPojo {@Resource   // Resource injection
private Datasource ds;@PostConstruct  // Life-cycle
private void init() {....
}
@Interceptors(LoggingInterceptor.class)public void myMethod() {...}
}

考虑到这一点， EJB ， REST和CDI bean呢？

• EJB bean服务–托管bean，具有公共服务（上述）并支持事务，安全性，线程安全性和持久性。
• REST bean服务–具有HTTP支持的托管bean
• CDI bean –具有生命周期的托管bean支持：
  • 自动发现

确切地说，Manage Bean最终是针对特定用途而扩展的SPI。 EJB，Rest，实体Bean都是托管Bean，但是容器提供了其他服务。 因此，如果您使用@Stateless或@Stateful批注定义POJO，则容器会自动检测到它是EJB bean，并且需要特定于容器的支持，例如事务，安全性，线程安全性，扩展等。

package mypackage;
import javax.ejb.Stateless;@Stateless
public class GreetingBean {public String greet(String name){return "Hello " + name;}
}

一个简单的POJO类就用一个手指（实际上是敲入）就变成了一个Stateless bean，从而产生了一个@Stateless代码。 与先验3.x上定义EJB的方式不同（这很痛苦）。

从此处下载示例（以上）： 单击我

自动Bean发现

CDI容器是负责如何发现Bean的容器，但是它是如何做到的？

1. 它首先扫描包含应用程序和容器档案的类路径。
   1. 它尝试扫描类路径，并查看标记为发现的POJO（即托管Bean）。 您可以考虑将其放入一个池中，并且当另一个Managed Bean通过注入对其进行调用时可以随时使用（有关下一个博客主题的更多信息）
2. 然后，它检测到bean.xml（或任何上下文xml文件定义）的存在。
   1. 对于Spring爱好者来说，这很像一个applicationContext.xml（至少是约定，但很松散）–您将XML传递到contextConfiguration侦听器（直通参数）上，Spring CDI Container会自动在其中标记对象（beans）以便发现–当然，您需要定义扫描机制（组件扫描）。

最终，引入DI / CDI是为了简化开发过程，统一技术以及整体以产生更强大，可扩展的应用程序。 让所有容器按照标记Bean的公共服务的方式工作，这使开发人员的任务更加轻松，而且比避免以前的框架导致的陷阱更重要。 SPI –实际上是改进的定义，它允许实际的JEE6框架可扩展，从而创造了更加动态的特性–业务应用程序架构师现在可以设计自己的框架和约定。 为自己的规则放置更多特定于业务的设计或注释，并提供企业应用程序始终需要的健壮性和灵活性。

下一主题： 基本进样 –我不想将所有内容放到一个帖子中，因此我将让您先吸收它并检查我创建的样本。 从现在开始，我将详细介绍DI和CDI的示例。

翻译自: https://www.javacodegeeks.com/2013/08/di-cdi-basics.html