JSF 支持 bean 结构(最佳实践) [英] JSF backing bean structure (best practices)

查看:25
本文介绍了JSF 支持 bean 结构(最佳实践)的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我希望在这篇文章中,我可以得到人们对 JSF 页面和支持 bean 之间接口的最佳实践的意见.

I hope that in this post, I can get people's opinions on best practices for the interface between JSF pages and backing beans.

我永远无法确定的一件事是我的支持 bean 的结构.此外,我从来没有找到一篇关于这个主题的好文章.

One thing that I never can settle on is the structure of my backing beans. Furthermore, I have never found a good article on the subject.

哪些属性属于哪些支持 bean?什么时候向给定的 bean 添加更多的属性而不是创建一个新的 bean 并将属性添加到它上面是合适的?对于简单的应用程序,考虑到将一个 bean 注入另一个 bean 所涉及的复杂性,为整个页面只使用一个支持 bean 是否有意义?支持 bean 应该包含任何实际的业务逻辑,还是应该严格包含数据?

What properties belong on which backing beans? When is it appropriate to add more properties to a given bean as opposed to creating a new bean and adding the properties onto it? For simple applications, does it make sense to just have a single backing bean for the whole page, considering the complexity involved with injecting one bean into another? Should the backing bean contain any actual business logic, or should it strictly contain data?

请随时回答这些问题以及可能出现的任何其他问题.

Feel free to answer these questions and any others that may come up.

为了减少 JSF 页面和支持 bean 之间的耦合,我从不允许 JSF 页面访问任何支持 bean 属性的属性.例如,我从不允许这样的事情:

As for reducing coupling between the JSF page and the backing bean, I never allow the JSF page to access any backing bean property's properties. For example, I never allow something such as:

<h:outputText value="#{myBean.anObject.anObjectProperty}" />

我总是需要这样的东西:

I always require something like:

<h:outputText value="#{myBean.theObjectProperty}" />

支持 bean 值为:

with a backing bean value of:

public String getTheObjectProperty()
{
    return anObject.getAnObjectProperty();
}

例如,当我循环遍历一个集合时,我使用一个包装类来避免深入到数据表中的对象.

When I loop over a collection, I use a wrapper class to avoid drilling down into an object in a data table, for instance.

总的来说,这种方法对我来说是正确的".它避免了视图和数据之间的任何耦合.如果我错了,请纠正我.

In general, this approach feels "right" to me. It avoids any coupling between the view and the data. Please correct me if I'm wrong.

推荐答案

你可能想看看这个:区分不同种类的 JSF 托管 bean.

以下是对 Neil Griffin 的上述文章中定义的不同 bean 类型的描述:

Here is a description of the different bean types, as defined in the above article by Neil Griffin:

  • Model Managed-Bean:通常的会话范围.这种类型的托管 bean 参与了 MVC 设计模式的模型"关注点.当你看到模型"这个词时——想想数据.JSF 模型 bean 应该是一个 POJO,它遵循 JavaBean 设计模式,使用 getter/setter 封装属性.模型 bean 最常见的用例是作为一个数据库实体,或者简单地表示数据库查询结果集中的一组行.
  • Backing Managed-Bean:通常是请求范围.这种类型的托管 bean 参与了 MVC 设计模式的视图"关注点.后台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 方法).
  • 支持托管Bean:通常是会话或应用程序范围.这种类型的bean支持"MVC设计模式的视图"关注点中的一个或多个视图.典型的用例是向出现在多个 JSF 视图中的 JSF h:selectOneMenu 下拉列表提供一个 ArrayList.如果下拉列表中的数据特定于用户,则 bean 将保留在会话范围内.但是,如果数据适用于所有用户(例如省份的下拉列表),则该 bean 将保留在应用程序范围内,以便为所有用户缓存.
  • Utility Managed-Bean:通常的应用范围. 这种类型的 bean 为一个或多个 JSF 视图提供某种类型的实用"功能.一个很好的例子可能是可以在多个 Web 应用程序中重用的 FileUpload bean.
  • Model Managed-Bean: Normally session scope. This type of managed-bean participates in the "Model" concern of the MVC design pattern. When you see the word "model" -- think DATA. A JSF model-bean should be a POJO that follows the JavaBean design pattern with getters/setters encapsulating properties. The most common use case for a model bean is to be a database entity, or to simply represent a set of rows from the result set of a database query.
  • Backing Managed-Bean: Normally request scope. This type of managed-bean participates in the "View" concern of the MVC design pattern. The purpose of a backing-bean is to support UI logic, and has a 1::1 relationship with a JSF view, or a JSF form in a Facelet composition. Although it typically has JavaBean-style properties with associated getters/setters, these are properties of the View -- not of the underlying application data model. JSF backing-beans may also have JSF actionListener and valueChangeListener methods.
  • Controller Managed-Bean: Normally request scope. This type of managed-bean participates in the "Controller" concern of the MVC design pattern. The purpose of a controller bean is to execute some kind of business logic and return a navigation outcome to the JSF navigation-handler. JSF controller-beans typically have JSF action methods (and not actionListener methods).
  • Support Managed-Bean: Normally session or application scope. This type of bean "supports" one or more views in the "View" concern of the MVC design pattern. The typical use case is supplying an ArrayList to JSF h:selectOneMenu drop-down lists that appear in more than one JSF view. If the data in the dropdown lists is particular to the user, then the bean would be kept in session scope. However, if the data applies to all users (such as a dropdown lists of provinces), then the bean would be kept in application scope, so that it can be cached for all users.
  • Utility Managed-Bean: Normally application scope. This type of bean provides some type of "utility" function to one or more JSF views. A good example of this might be a FileUpload bean that can be reused in multiple web applications.

这篇关于JSF 支持 bean 结构(最佳实践)的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆