在不同种类的JSF管理豆之间做出区分

Lau*_*ens 45 java jsf java-ee backing-beans

我最近阅读了来自Neil Griffin的这篇文章,在不同种类的JSF Managed-Beans之间做出区分,这让我想到了我自己的应用程序中不同bean之间的区别.要快速总结一下要点:

  • Model Managed-Bean:这种类型的托管bean参与MVC设计模式的"模型"关注.当你看到"模型"这个词时 - 想想数据.JSF模型bean应该是遵循JavaBean设计模式的POJO,其中getter/setter封装属性.

  • 支持托管Bean:这种类型的托管bean参与MVC设计模式的"视图"关注.backing-bean的目的是支持UI逻辑,并且与Facef组合中的JSF视图或JSF表单具有1 :: 1的关系.虽然它通常具有带有关联getter/setter的JavaBean样式属性,但它们是View的属性 - 而不是底层应用程序数据模型的属性.JSF支持bean也可能有JSF actionListener和valueChangeListener方法.

  • Controller Managed-Bean:这种类型的托管bean参与MVC设计模式的"Controller"关注.控制器bean的目的是执行某种业务逻辑并将导航结果返回给JSF导航处理程序.JSF控制器bean通常具有JSF操作方法(而不是actionListener方法).

  • 支持Managed-Bean:这种类型的bean"支持"MVC设计模式的"View"关注中的一个或多个视图.典型的用例是向JSF h:selectOneMenu下拉列表提供ArrayList,这些列表出现在多个JSF视图中.如果下拉列表中的数据特定于用户,则bean将保留在会话范围内.

  • Utility Managed-Bean:这种类型的bean为一个或多个JSF视图提供某种类型的"实用程序"功能.一个很好的例子可能是FileUpload bean,它可以在多个Web应用程序中重用.

这对我来说很有意义,在过去的几个小时里,我一直在重构我的代码,并针对用户登录提出以下内容:

AuthenticationController是Controller Managed-Bean的一个例子.它是请求范围的,具有两个用于设置用户名和密码的getter和setter,以及两种导航方法,authenticatelogout在成功登录时将用户导航到其私有区域,或者在注销时返回主页面.

UserBean是一个支持管理Bean的示例.它是会话范围的,并且具有User类的实例(当您未经过身份验证时将使用getter和setter,它将为null),仅此而已.

AuthenticationController有这个用户作为托管属性(@ManagedProperty(value = "#{userController.user} private User user;).验证成功后,AuthenticationController将使用用于登录的相应用户名将托管属性设置为实际用户实例.

任何新的bean都可以将用户作为托管属性获取并提取他们需要的数据,例如组成员资格,如果User该类具有包含组名的列表.

这种方式是关于分离问题的正确方法吗?

Bal*_*usC 89

这是一个非常主观的问题.我个人不同意这篇文章,并发现它给初学者提供了非常糟糕的建议.


Model Managed-Bean:这种类型的托管bean参与MVC设计模式的"模型"关注.当你看到"模型"这个词时 - 想想数据.JSF模型bean应该是遵循JavaBean设计模式的POJO,其中getter/setter封装属性.

我绝对不会把它称为托管bean.只要把它变成一个属性@ManagedBean.例如DTO或JPA @Entity.


支持托管Bean:这种类型的托管bean参与MVC设计模式的"视图"关注.backing-bean的目的是支持UI逻辑,并且与Facef组合中的JSF视图或JSF表单具有1 :: 1的关系.虽然它通常具有带有关联getter/setter的JavaBean样式属性,但它们是View的属性 - 而不是底层应用程序数据模型的属性.JSF支持bean也可能有JSF actionListener和valueChangeListener方法.

这样,您可以在托管bean中复制和映射实体的属性.这对我来说毫无意义.如上所述,只需将实体作为托管bean的属性,让输入字段直接引用它#{authenticator.user.name}而不是#{authenticator.username}.


Controller Managed-Bean:这种类型的托管bean参与MVC设计模式的"Controller"关注.控制器bean的目的是执行某种业务逻辑并将导航结果返回给JSF导航处理程序.JSF控制器bean通常具有JSF操作方法(而不是actionListener方法).

这几乎描述了@RequestScoped/ @ViewScoped @ManagedBeanclass.是否允许事件侦听器方法取决于它们是否特定于与bean绑定的视图和/或它们的作业是否依赖于bean的状态.如果是,那么它们属于豆.如果没有,那么它们应该是任何FacesListener接口的独立实现,但绝对不是托管bean.


支持Managed-Bean:这种类型的bean"支持"MVC设计模式的"View"关注中的一个或多个视图.典型的用例是向JSF h:selectOneMenu下拉列表提供ArrayList,这些列表出现在多个JSF视图中.如果下拉列表中的数据特定于用户,则bean将保留在会话范围内.

精细.对于应用程序范围的数据,如下拉列表,只需使用@ApplicationScopedbean,对于会话范围的数据,如登录用户及其首选项,只需使用@SessionScoped一个.


Utility Managed-Bean:这种类型的bean为一个或多个JSF视图提供某种类型的"实用程序"功能.一个很好的例子可能是FileUpload bean,它可以在多个Web应用程序中重用.

这对我来说不是很有意义.支持bean通常与单个视图绑定.这听起来太像一个ActionListener实现,它将由<f:actionListener>命令组件用于您的选择.绝对不是托管bean.

有关正确方法的启动示例,另请参阅:

  • +1我不能完全支持这个答案!我读了一百遍同样的文章,并花了一些时间试图遵循它的建议,直到我放弃,因为我复制这么多东西没有意义...... (8认同)
  • 谢谢BalusC!我想我需要弄清楚,有一个严格的规则,以某种方式组织一个项目,更务实,而不是挂在这些文章上,强迫自己坚持. (3认同)
  • 谢谢BalusC.最初这篇文章很有意义,因为我是JSF的新手,但在玩了我的bean后,你的更新更有意义. (2认同)