java - JSF 支持 bean 结构(最佳实践)

Question

我希望在这篇文章中，我可以得到人们对 JSF 页面和 backing beans 之间接口(interface)的最佳实践的意见。

我永远无法解决的一件事是我的支持 bean 的结构。此外，我从来没有找到关于这个主题的好文章。

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

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

---

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

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

我总是需要类似的东西:

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

支持 bean 值为:

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

例如，当我遍历一个集合时，我使用一个包装类来避免向下钻取到数据表中的对象。

总的来说，这种方法对我来说是“正确的”。它避免了 View 和数据之间的任何耦合。如果我错了，请纠正我。

Answer 1

您可能想看看这个:making distinctions between different kinds of JSF managed beans .

这里是对不同 bean 类型的描述，正如 Neil Griffin 在上述文章中所定义的那样:

• Model Managed-Bean:通常是 session 范围。这种类型的托管 bean 参与了 MVC 设计模式的“模型”关注点。当你看到“模型”这个词时——想想 DATA。 JSF 模型bean 应该是遵循JavaBean 设计模式的POJO，其中getter/setter 封装了属性。模型 bean 最常见的用例是作为数据库实体，或者简单地表示数据库查询结果集中的一组行。
• 支持 Managed-Bean:通常请求范围。这种类型的托管 bean 参与 MVC 设计模式的“ View ”关注点。 backing-bean 的目的是支持 UI 逻辑，并且与 JSF View 或 Facelet 组合中的 JSF 表单具有 1::1 的关系。尽管它通常具有带有关联 getter/setter 的 JavaBean 样式属性，但这些是 View 的属性，而不是底层应用程序数据模型的属性。 JSF backing-beans 也可能有 JSF actionListener 和 valueChangeListener 方法。
• Controller Managed-Bean:通常请求范围。这种类型的托管 bean 参与 MVC 设计模式的“ Controller ”关注点。 Controller bean 的目的是执行某种业务逻辑并将导航结果返回给 JSF 导航处理程序。 JSF Controller bean 通常具有 JSF 操作方法(而不是 actionListener 方法)。
• 支持 Managed-Bean:通常是 session 或应用程序范围。 这种类型的 bean“支持”MVC 设计模式的“ View ”关注点中的一个或多个 View .典型的用例是向 JSF h:selectOneMenu 提供一个 ArrayList 下拉列表，该下拉列表出现在多个 JSF View 中。如果下拉列表中的数据对用户来说是特定的，那么 bean 将保留在 session 范围内。但是，如果数据适用于所有用户(例如省份的下拉列表)，则 bean 将保留在应用程序范围内，以便可以为所有用户缓存。
• Utility Managed-Bean:通常是应用程序范围。这种类型的 bean 为一个或多个 JSF View 提供某种类型的“实用程序”功能。一个很好的例子可能是可以在多个 Web 应用程序中重用的 FileUpload bean。