java - CDI 世界中的 REST 应用程序设计选择

Question

我有 JAX-RS 资源类调用单独服务类中的方法。我为资源类和服务类选择了 @RequestScoped，这样我就可以轻松地提供(@Inject 一个常见的 CDI 实例)并将响应从服务类传递回资源类。

问题是服务类提供的方法对具有 @ApplicationScoped、@Dependent 或 @Stateless 作用域的其他类有用。但是响应类的注入(inject)不再有帮助，因为后端类没有 @RequestScope 上下文。

我想我有几个选择

• 将服务类更改为 @Stateless 或 @Dependent 并放弃使用 CDI 来共享公共(public)响应类实例，而是从服务类返回可由任何调用者解释的通用响应(不是特定于 REST 的)。这将由资源类转换为 REST 响应。
• 通过将大量服务类分解为 @Dependent 类来创建一个附加层，这些类可以从 @RequestScoped 服务层或后端 @Application/@Dependent 类调用。
• 我还没想到的事情

有人可以分享一下他们如何使用 CDI 设计这样的应用程序吗？

Answer 1

我要回答我自己的问题。

使用 @RequestScoped 的诱惑似乎可以简化应用程序设计，但从更大的角度来看，它显然增加了复杂性。

Adam Bien 证明，制作 JAX-RS 边界类 EJB (@Stateless) 可以获得比 @RequestScoped 更好的性能，因此现在的问题变成了将结果从服务层传递回请求层或可能传递到另一个类这不是边界的一部分。

完全消除服务类并将控制类直接注入(inject)边界可能是更好的方法。控制类可以是 @Dependant、@Stateless 或 @Application 范围的(我猜？)。

还值得注意的是，如果您决定创建替代资源，例如 @RequestScoped 服务类无论如何都不会为您购买任何东西。 websocket API，因为它不会有与您的服务类相同的@RequestScope!