什么是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中使用前端控制器的项目,并将所有业务Data对象注入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视图范围).