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

Question

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

@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中只有一个控制器，它包含所有业务值并提供在无状态ejbs中实现的业务方法。 在另一种情况下，在RequestScopde中使用了一个控制器，并且在SessionScope中有很多BusinessValue对象被实现为MangedBeans，这些对象被注入到控制器bean中。

我的问题是：将Session EJB注入SessionScope Managed bean通常是不好的做法吗？

Answer 1

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

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

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

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

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

如果您需要在某种流程中跨越多个页面，您可以选择通过GET参数传递数据，如果它涉及已经存在的数据并且您可以为其传递ID数据。否则你可能想看看对话范围。

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