JSF 托管 bean 和无状态 EJB 的最佳模式是什么答案

【问题标题】：Whats the best pattern for JSF managed beans and stateless EJBsJSF 托管 bean 和无状态 EJB 的最佳模式是什么
【发布时间】：2012-08-31 19:24:28
【问题描述】：

关于会话范围和请求范围，您认为实现 JSF 托管 bean 的最佳方式是什么？就我而言，我有一个带有 EJB 模块和 Web 模块的 EAR 应用程序。 EJB 模块提供无状态会话 bean。现在，在 Web 模块中，我在 sessionScope 中使用了 ManagedBean。该 bean 注入了一些无状态会话 ejb 并保存了一些包含业务数据的值对象，这些数据可以在不同的页面中使用。

@Named("workflowController")
@SessionScoped
public class WorkflowController {
    private List<ItemCollection> someList;
    private ItemCollection someBusinessData;
    /* Services */
    @EJB
    private MyService myService;

bean 为前端提供了很多操作方法，并利用了无状态会话 bean。这是一般的好习惯吗？或者我应该更改我的控制器以请求范围？我见过前端控制器仅在 RequestScoped 中使用并将所有业务数据对象注入为 managedProperties 的项目，这些对象在 SessionScope 中作为 ManagedBeans 实现。

在我的示例中，我在 SessionScope 中只有一个控制器持有所有业务值并提供在无状态 ejb 中实现的业务方法。在另一种情况下，RequestScopde 中使用了一个控制器，并且有许多 BusinessValue 对象在 SessionScope 中实现为 MangedBeans，这些对象被注入到控制器 bean 中。

我的问题是：一般来说，将 Session EJB 注入到 SessionScope Managed bean 中是不好的做法吗？

【问题讨论】：

有些人似乎在没有提供解释的情况下快速使用减号/关闭手...一个有效的问题 IMO

标签： jsf ejb managed-bean

【解决方案1】：

如果会话范围的托管 bean 需要访问业务逻辑，那么将无状态 EJB 注入其中并不是一个坏习惯。

过度使用会话范围的 bean 可能是一种不好的做法。

仅将会话范围的 bean 用于 HTTP 会话真正全局的事物，例如有关当前登录用户或购物车的详细信息。请注意，当用户在浏览器中打开多个窗口或选项卡时，会话范围的 bean 可能会受到竞争条件的影响。

在具有数十到数百个页面的典型 Web 应用程序中，通常最多应该只有少数会话范围的 bean。

对于支持单个页面的托管 bean（称为支持 bean），视图范围通常是 JSF 中最合适的范围。根据页面的确切作用，请求范围也可能是合适的。根据经验，当最初请求页面时加载数据时，回发后也需要该数据，请使用视图范围。如果没有此类数据，请尝试是否可以摆脱请求范围。

如果您需要在一种流中跨越多个页面，如果涉及已持久化的数据并且您可以传递它们的 Id，则可以选择通过 GET 参数传递数据。否则，您可能想查看对话范围。

不幸的是，JSF 2.1 及之前的版本本身不支持 CDI 托管 bean 的视图范围，但像 CODI 这样的第三方项目提供了一个实现（JSF 2.2 很可能会支持开箱即用的 CDI 视图范围）。

【讨论】：

感谢您的详细解答。这对我很有帮助。