java - 将@Scoped 与EJB 一起使用有什么意义？

Question

通常我使用 @RequestScoped 或 @SessionScoped(来自 javax.enterprise.context)来注入(inject)对象(例如在人脸中beans)使用@Inject。我也在使用 EJB。据我了解，一组无状态 EJB 副本(池)用于注入(inject)对象。存在多个副本的原因是为了确保不会同时访问一个 EJB 实例。在谈到有状态 EJB 时(同样是我所理解的)，其中一个实例绑定(bind)到具体的注入(inject)点。它们是使用 @EJB 注入(inject)的(也是无状态的)。

我经常可以在网络上看到将 @Stateless 或 @Stateful 与 @Scoped 结合使用的示例。它们的含义是什么？

编辑:(试图澄清，因为此时没有人回应):

我特别感兴趣的是，在创建 EJB 实例的那一刻，这种范围内的注释是否会以任何方式(以及如果它们如何)发生变化。根据我的理解:如果我有 @EJB 注释字段，则会在那里注入(inject)适当类的对象。如果此类 EJB 是无状态的，则容器只需从预先创建的实例池中获取免费实例即可。如有必要，可以调整池的大小。它是无状态的，因为不能保证在我们类(即具有包含对 EJB 的引用的字段的类)的方法调用中保留对象。

我们还可以使用有状态 EJB，在这种情况下，在方法调用期间会保留一个实例。正如我所想，它会在每次创建对象时简单地注入(inject)一次。 (还有单例EJB，所有对象之间共享)。

我在这里找不到 EJB 的 @Scoped 注释的用途。

编辑 2:

如果要通过 EJB 和 DI(通过 @Inject)机制注入(inject)类，则可以使用这种注释组合。然而，这是一种特殊情况，并不优雅。我问你是否知道任何其他原因。

编辑 3:请在 arjan 的回答下查看我的评论。

Answer 1

@Stateless 或@Singleton bean 可以被显式限定范围以防止其范围被自动修改为可能非法的范围。例如。这两种 bean 类型都不允许是 @RequestScoped。有关更多信息，请参阅此链接:http://docs.jboss.org/resteasy/docs/2.0.0.GA/userguide/html/CDI.html

@Stateful 具有(显式)范围的意义。也就是说，如果没有范围，作为程序员，您必须小心调用 @Remove 注释的方法。这可能很难保证，因为这样的 bean 通常不会在您可以在 finally block 中调用 @Remove 方法的单个方法中使用。使用范围，当范围结束时，bean 将被完全删除。

此外，如果没有作用域，您将无法始终使用注入(inject)来获取对有状态 bean 的 stub 的引用。也就是说，每次注入(inject)发生时，您都会得到一个新实例。在请求范围 (JSF) 支持 bean 中注入(inject)有状态 bean 时，这尤其麻烦，因为您有意在多个请求中保留有状态 bean。

然后，结合 @Named，您还可以直接使用 session bean 作为支持 bean 来扁平化您的应用程序层(参见例如 http://jaxenter.com/java-ee-6-overview-35987-2.html)。显然，在这种情况下您需要一个明确的范围。现在，在大型应用程序中扁平化层可能不是最佳实践，但对于小型应用程序和/或刚开始使用 Java EE 的人来说，肯定希望将业务逻辑直接放入支持 bean 中。然后要求支持 bean 可以访问“业务 bean”通常具有的相同类型的服务(主要是事务)。

最后，Gavin King(CDI 规范负责人)建议始终使用@Inject 而不是@EJB。唯一的异常(exception)涉及远程 EJB，其中仍使用 @EJB。

围绕 EJB 和 CDI 的部分混淆是 CDI 是 Java EE 中的一种新组件模型，而且仍然相对较新。尽管它们彼此集成得很好，但它们仍然是两个不同的组件模型，并且尚未考虑到所有最佳实践。 Reza Rahman(EG 成员、EJB 书籍作者和 CDI 实现 CanDI 的作者)建议 EJB 模型可能在未来作为一组 CDI 服务进行改造。事实上，在 Java EE 7 中，通过将事务服务与 EJB 分离并通过 (CDI) 注释使它们可用，迈出了一步。