CDI 和 EJB 相比如何？相互影响？

Question

我很难理解两者如何相互作用以及它们之间的界限在哪里。它们重叠吗？他们之间有裁员吗？

我知道两者都有相关的注释，但我无法找到两者的完整列表和简短描述。不确定这是否有助于澄清它们的不同之处或重叠之处。

真的只是很困惑。我（认为我）对 EJB 相当了解，我想我很难准确理解 CDI 带来的内容以及它如何取代或增强 EJB 已经提供的功能。

Answer 1

目前确实有点令人困惑，因为 Java EE 中有多个组件模型。它们是CDI、EJB3 和JSF Managed Beans。

CDI 是新来的。 CDI bean 具有依赖注入、作用域和事件总线功能。 CDI bean 在注入和范围界定方面是最灵活的。事件总线非常轻量级，甚至非常适合最简单的 Web 应用程序。除此之外，CDI 还公开了一个非常先进的功能，称为“可移植扩展”，这是一种插件机制，供供应商为 Java EE 提供额外的功能，这些功能可在所有实现上使用（ Glassfish、JBoss AS、Websphere 等）。

EJB3 bean 是从旧的 EJB2 组件模型^* 改造而来的，并且是 Java EE 中第一个通过注释进行管理的 bean。 EJB3 bean 具有依赖注入、声明性事务、声明性安全性、池化、并发控制 >、异步执行和远程处理。

EJB3 bean 中的依赖关系注入不如 CDI bean 灵活，并且 EJB3 bean 没有作用域概念。然而，EJB3 bean 是事务性的并且默认是池化的^**，CDI 选择将这两个非常有用的东西留在 EJB3 的领域中。其他提到的项目在 CDI 中也不可用。 EJB3 虽然没有自己的事件总线，但它确实有一种特殊类型的 bean 用于监听消息；消息驱动 bean。这可用于从 Java 消息系统或任何其他具有 JCA 资源适配器的系统接收消息。对简单事件使用完整的消息传递比 CDI 事件总线重量级得多，并且 EJB3 只定义了侦听器，而不是生成器 API。

自从包含 JSF 以来，JSF Managed Beans 就存在于 Java EE 中。它们还具有依赖注入和作用域功能。 JSF Managed Beans 引入了声明性作用域的概念。最初范围相当有限，在同一版本的 Java EE 中，EJB3 bean 已经可以通过注释声明，而 JSF Managed Beans 仍然必须在 XML 中声明。当前版本的 JSF Managed Beans 最终也是通过注释声明的，并且范围通过视图范围和创建自定义范围的能力进行了扩展。视图作用域会记住对同一页面的请求之间的数据，这是 JSF Managed Beans 的一个独特功能。

除了视图范围之外，Java EE 6 中的 JSF Managed Beans 几乎没有什么用处。CDI 中缺少视图范围是不幸的，因为否则 CDI 将是 JSF Managed Beans 提供的完美超集。 更新：在 Java EE 7/JSF 2.2 中，CDI 兼容 @ViewScoped 已添加，使 CDI 确实成为完美的超级套装。 更新 2：在 JSF2.3 中，JSF 托管 Bean 已被弃用，取而代之的是 CDI 托管 Bean。

对于 EJB3 和 CDI，情况并不是那么明确。 EJB3 组件模型和 API 提供了许多 CDI 不提供的服务，因此通常 EJB3 不能被 CDI 替代。另一方面，CDI 可以与 EJB3 结合使用 - 例如，向 EJB 添加范围支持。

Reza Rahman 是专家组成员，也是名为 CanDI 的 CDI 实现的实现者，他经常暗示与 EJB3 组件模型相关的服务可以作为一组 CDI 注释进行改进。如果发生这种情况，Java EE 中的所有托管 bean 都可能成为 CDI bean。这并不意味着 EJB3 消失或过时，只是它的功能将通过 CDI 公开，而不是通过 EJB 自己的注释（如 @Stateless 和 @EJB）公开。

更新

TomEE 和 OpenEJB 出名的 David Blevins 在他的博客上很好地解释了 CDI 和 EJB 之间的区别和相似之处：CDI，何时中断 EJB

_{*
虽然这只是版本号的增加，但 EJB3 bean 在很大程度上是一种完全不同类型的 bean：一个简单的 pojo，通过应用简单的单个注释成为“托管 bean”，而 EJB2 中的模型则需要重量级且过度的注释。每个 bean 都需要详细的 XML 部署描述符，此外，该 bean 需要实现各种极其重量级且大部分无意义的组​​件接口。}

_{** 无状态会话 bean 通常是池化的、有状态的会话 Bean 通常不会（但也可以是）。因此，对于这两种类型，池化都是可选的，并且 EJB 规范并未强制要求采用任何一种方式。}

Answer 2

CDI：它是关于依赖注入的。这意味着您可以在任何地方注入接口实现。这个对象可以是任何东西，它可以与EJB无关。 这里是如何使用 CDI 注入随机生成器的示例。没有任何关于EJB的内容。当您想要注入非 EJB 服务、不同的实现或算法时，您将使用 CDI（因此您根本不需要 EJB）。
EJB：您确实了解，并且可能您对 @EJB 注释感到困惑 - 它允许您将实现注入到您的服务或其他内容中。主要思想是您注入的类应该由 EJB 容器管理。
似乎 CDI 确实了解 EJB 是什么，因此在兼容 Java EE 6 的服务器中，您可以在 servlet 中同时编写这两种内容

@EJB EJBService ejbService;

，

@Inject EJBService ejbService;

这可能会让您感到困惑，但这可能是 EJB 和 CDI 之间唯一的桥梁。

当我们谈论 CDI 时，您可以将其他对象注入到 CDI 托管类中（它们应该由 CDI 感知框架创建）。

CDI 还提供什么...例如，您使用 Struts 2 作为 MVC 框架（仅示例），即使使用 EJB 3.1，您也受到限制 - 您不能在 Struts 中使用 @EJB 注释动作，它不受容器管理。但是当您添加 Struts2-CDI 插件时，您可以为同一件事编写 @Inject 注释（因此不再需要 JNDI 查找）。这样它增强了 EJB 的功能，但是正如我之前提到的，您用 CDI 注入的内容 - 是否与 EJB 相关并不重要，这就是它的功能。

附言。更新了示例的链接

Answer 3

Albert Einstein：如果你不能简单地解释它，说明你还没有理解它

Ejbs 和 CDI 非常容易理解。

Ejbs：

1. 始终用范围限定符进行注释，例如@Stateless、@Stateful、@Request 等。Ejbs
2. 的实例由Java EE 框架控制并池化。 EE框架的职责是为消费者提供实例。

@Stateless

 public class CarMaker(){
    public void createCar(Specification specs){
        Car car = new Car(specs);
    }
}

CarMaker 使用特定的 Ejbs 范围进行注释，因此，它是 Ejb

CDI：

1. 不完全由 EE 框架管理，必须自己创建实例。

2. 它总是依赖的。让我用例子来解释“依赖”：

   类规范{
私有字符串颜色；
私有字符串模型；
//- Getter 和 Setter
}

Specification 类是 CDI，因为它没有用 Ejb 范围进行注释，而且它必须由您的代码而不是 EE 框架初始化。
这里需要注意的一点是，由于我们没有对Specification类进行注解，所以它默认是通过@Dependent注解进行注解的。

@Dependent  <- By default added 
class Specification { ... }

延伸阅读：您需要对Ejbs范围注释和CDI范围注释进行更多研究，这将进一步明确概念。