JAX-RS 资源作为 POJO、CDI 和 EJB答案

【问题标题】：JAX-RS resource as POJO vs CDI vs EJBJAX-RS 资源作为 POJO、CDI 和 EJB
【发布时间】：2019-03-01 01:26:26
【问题描述】：

JAX-RS 根资源由 @Path 注释定义，并且可能使用托管组件来完成实际工作，例如：

@Path("resource")
public class Resource
{
  @Inject
  Worker worker;

  @GET
  public String getDetails() {
    return worker.getDetails();
  }
}

现在我可以将此 JAX-RS 根资源传输到 CDI bean：

@RequestScoped
@Path("resource")
public class Resource {...}

或者到 EJB：

@Stateless
@Path("resource")
public class Resource {...}

那么 - 以 POJO、CDI 或 EJB 方式执行它的后果是什么？从外部看，对 URL 的请求提供了三倍于相同的东西，但在幕后会发生什么以及注入的组件与每种情况有何关系？

【问题讨论】：

出于好奇，为什么还要将此 JAX-RS 类设为 EJB 或显式 CDI 托管 bean？
@Kukeltje：例如，因为托管组件提供的功能，如事务、池、管理。并且通常定义一个事务边界。
我总是把它们放在服务上，而不是放在前端类上。我保持这些干净/简单（在我的例子中是我的 jax-rs 和 jsf），但可能有充分的理由将我从未意识到的东西结合起来。
@Kukeltje 不是每个人都使用弹簧。如果他在一个 EE 容器中，那么 spring 提供的 95% 的东西都已经过时了（除了添加 spring-batch 等模块）。他的问题是有道理的。最终，它归结为上下文。
@him：我不使用弹簧，从来没有，永远不会。所有的 ejb 和 cdi 都适合我。 “关注点分离”......在这个意义上的服务。我不知道你会认为我在谈论春天

【解决方案1】：

这几乎可以归结为上下文。您是否需要 EJB 提供的额外设施（明确定义的事务语义、代理无状态池处理程序、集群支持等），还是只需要依赖注入？

只要使用 CDI bean 就可以满足您的需求，如果这就是您所需要的。如果您甚至不需要它，POJO 将为您提供最简单的收益。

【讨论】：