我在单独的服务类中有JAX-RS资源类调用方法。我为资源和服务类都选择了@RequestScoped，以便可以轻松提供（@Inject一个通用的CDI实例）并将响应从服务类传递回资源类。
问题在于服务类提供的方法对于@ ApplicationScoped，@ Dependent或@Stateless范围的其他类将很有用。但是注入响应类不再有帮助，因为后端类没有@RequestScope上下文。
我想我有几种选择
将服务类更改为@Stateless或@Dependent，并放弃使用CDI共享一个公共响应类实例，而是从该服务类返回一个可以由任何调用者（非REST特定）解释的通用响应。资源类会将其转换为REST响应。
通过将大量服务类分解为@Dependent类来创建附加层，可以从@RequestScoped服务层或后端@ Application / @ Dependent类调用这些类。
我还没想到的事
有人可以分享他们如何使用CDI设计这样的应用程序吗？
最佳答案
我要回答我自己的问题。
使用@RequestScoped的诱惑似乎简化了应用程序设计，但是在更大的背景下很明显它增加了复杂性。
亚当·比恩（Adam Bien）演示了使JAX-RS边界类EJB（@Stateless）比@RequestScoped产生更好的性能，因此，现在的问题变成了将结果从服务层传递回请求层或传递给另一个非请求类的问题。边界的一部分。
完全消除服务类并将控制类直接注入边界可能是一种更好的方法。控制类可以是@ Dependant，@ Stateless或@Application作用域（我想是？）。
同样值得注意的是，如果您决定创建替代资源，例如@RequestScoped服务类将不会为您带来任何好处。一个websocket API，因为它与服务类的@RequestScope都不一样！