区分不同类型的JSF托管项目

我最近阅读了Neil Griffin的这篇文章,对不同类型的JSF Managed-Beans进行了区分,并让我思考了我自己的应用程序中不同bean之间的区别。 要快速总结这个要点:

  • Model Managed-Bean:这种类型的托管bean参与了MVC设计模式的“Model”关注。 当你看到“模型”这个词 - 想想DATA。 JSF模型bean应该是一个遵循JavaBean设计模式的POJO,使用getter / setter封装属性。

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

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

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

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

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

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

    UserBean是Support Managed Bean的示例。 它是会话范围的,并且以getter和setter为特征,具有User类的实例(当您未通过身份验证时该类将为null),仅此而已。

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

    任何新的bean都可以将用户作为托管属性来获取,并且如果User类包含具有组名称的列表,则可以提取他们需要的数据,例如组成员身份。

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


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


    Model Managed-Bean:这种类型的托管bean参与了MVC设计模式的“Model”关注。 当你看到“模型”这个词 - 想想DATA。 JSF模型bean应该是一个遵循JavaBean设计模式的POJO,使用getter / setter封装属性。

    我绝对不会把它称为托管bean。 只需将其设置为@ManagedBean的属性即可。 例如DTO或JPA @ @Entity


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

    这样你就可以不断复制和映射托管bean中实体的属性。 这对我来说没有意义。 如上所述,只需使实体成为托管bean的属性,并让输入字段直接引用它,如#{authenticator.user.name}而不是#{authenticator.username}


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

    这几乎描述了@RequestScoped / @ViewScoped @ManagedBean类。 事件监听器方法是否被允许取决于它们是特定于与bean绑定的视图,还是依赖于bean的状态。 如果他们是,那么他们属于豆。 如果不是,那么它们应该是任何FacesListener接口的独立实现,但绝对不是托管bean。


    支持Managed-Bean:这种类型的bean在MVC设计模式的“View”关注中“支持”一个或多个视图。 典型的用例是将ArrayList提供给出现在多个JSF视图中的JSF h:selectOneMenu下拉列表。 如果下拉列表中的数据对用户是特定的,那么该bean将保持在会话范围内。

    精细。 对于像下拉列表这样的应用程序范围的数据,只需使用@ApplicationScoped bean,对于会话范围的数据,如登录用户及其首选项,只需使用@SessionScoped


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

    这对我来说并不真实。 备份豆通常绑定到单个视图。 这听起来很像ActionListener实现,它将被您的选择的命令组件中的<f:actionListener>使用。 绝对不是托管bean。

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

  • 我们的JSF wiki页面中的Hello World示例
  • “书店CRUD”这个答案的例子
  • 这个答案中的“主 - 细节”示例
  • JSF服务层
  • JSF 2中的通信
  • 链接地址: http://www.djcxy.com/p/49109.html

    上一篇: Making Distinctions Between Different Kinds of JSF Managed

    下一篇: Best way to compute a truncated singular value decomposition in java