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

问题描述

我希望在这篇文章中，我可以得到人们对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.

我永远无法解决的一件事on是我的支持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}" />

我总是要求：

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

支持bean值为：

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应该是遵循JavaBean设计模式的POJO，其中getter / setter封装属性。模型bean最常见的用例是数据库实体，或者只是表示数据库查询结果集中的一组行。


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


• Controller Managed-Bean ：通常请求范围。这种类型的managed-bean参与MVC设计模式的Controller关注。控制器bean的目的是执行某种业务逻辑并将导航结果返回给JSF导航处理程序。 JSF控制器bean通常具有JSF操作方法（而不是actionListener方法）。


• 支持Managed-Bean ：通常是会话或应用程序范围。这种类型的bean支持MVC设计模式的视图关注中的一个或多个视图。典型的用例是向JSF h：selectOneMenu下拉列表提供一个ArrayList，该列表出现在多个JSF视图中。如果下拉列表中的数据特定于用户，则bean将保留在会话范围内。但是，如果数据适用于所有用户（例如省份的下拉列表），则bean将保留在应用程序范围内，以便可以为所有用户缓存。


• 实用程序托管Bean ：通常是应用程序范围。这种类型的bean为一个或多个JSF视图提供某种类型的实用程序功能。一个很好的例子可能是FileUpload bean，它可以在多个Web应用程序中重用。

• 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屋！