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

问题

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

我永远无法解决的一件事是我的支持豆的结构。此外,我从未找到关于这个主题的好文章。

什么属性属于哪个支持bean?何时适合向给定bean添加更多属性,而不是创建新bean并将属性添加到其中?对于简单的应用程序,考虑到将一个bean注入另一个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();
}

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

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


#1 热门回答(141 赞)

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

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

  • Model Managed-Bean:通常是会话范围。这种类型的托管bean参与了MVC设计模式的"模型"关注。当你看到"模型"这个词时 - 想想数据。 JSF模型bean应该是遵循JavaBean设计模式的POJO,其中getter / setter封装属性。模型bean的最常见用例是数据库实体,或者只是表示数据库查询结果集中的一组行。
  • Backing Managed-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设计模式的"控制器"关注。控制器bean的目的是执行某种业务逻辑并将导航结果返回给JSF导航处理程序。 JSF控制器bean通常具有JSF操作方法(而不是actionListener方法)。
  • 支持Managed-Bean:通常是会话或应用程序范围。这种类型的bean"支持"MVC设计模式的"视图"关注中的一个或多个视图。典型的用例是向JSF h:selectOneMenu下拉列表提供一个ArrayList,该列表出现在多个JSF视图中。如果下拉列表中的数据特定于用户,则bean将保留在会话范围内。但是,如果数据适用于所有用户(例如省份的下拉列表),则bean将保留在应用程序范围内,以便可以为所有用户缓存该数据。
  • Utility Managed-Bean:通常是应用程序范围。这种类型的bean为一个或多个JSF视图提供了某种类型的"实用程序"功能。一个很好的例子可能是FileUpload bean,它可以在多个Web应用程序中重用。

#2 热门回答(14 赞)

好问题。当我搬到JSF时,我遇到了同样的困境。这真的取决于你的应用程序。我来自Java EE世界所以我建议尽可能少地使用后台bean中的业务逻辑。如果逻辑纯粹与页面的显示有关,那么将它放在辅助bean中就可以了。

我相信JSF的(许多)优势之一实际上是你可以直接在托管bean上公开域对象。因此,我强烈推荐使用<:outputText value="#{myBean.anObject.anObjectProperty}" />方法,否则你最终会为自己手动曝光每个属性做太多工作。此外,如果封装了所有属性,插入或更新数据时会有点混乱。在某些情况下,单个域对象可能不够用。在这些情况下,我在将它暴露在bean上之前准备一个ValueObject。
编辑:实际上,如果你打算封装你想要公开的每个对象属性,我建议你将UI组件绑定到支持bean,然后将内容直接注入组件的值。
就bean结构而言,我的转折点是当我强行忽略了所有关于构建Web应用程序的知识并开始将其视为GUI应用程序时。 JSF模仿Swing很多,因此开发Swing应用程序的最佳实践大多也适用于构建JSF应用程序。


#3 热门回答(4 赞)

我可能不会回答你的每一个问题,因为很少有人似乎完全依赖于个案。

  • 在你的支持bean中有一个业务逻辑很好。这取决于你来自哪里。如果你正在练习域驱动设计,那么你将很想将业务逻辑包含在支持bean中,或者也可能是持久性逻辑。他们争辩说为什么这么愚蠢的对象。对象不仅应该携带状态,还应该携带行为。另一方面,如果你考虑传统的Java EE工作方式,你可能会感觉在支持bean中有数据,也可能是你的实体bean,以及某些会话bean中的其他业务和持久性逻辑。那也没关系。
  • 完整页面上有单个支持bean是完全没问题的。我没有看到任何问题。这看起来可能不正确,但这取决于具体情况。
  • 你的另一个问题更多地取决于你手头的情况。我更喜欢在这里进行域驱动,可能适合向现有域添加属性,或者为此创建新bean。哪个更适合。我认为没有任何灵丹妙药。
  • 哪些属性属于哪个辅助bean。那么,它不依赖于域对象吗?或者问题可能不是那么清楚。

而且,在你给定的代码示例中,我没有看到任何巨大的好处。