问题
我希望在这篇文章中，我可以得到人们对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。那么，它不依赖于域对象吗？或者问题可能不是那么清楚。
而且，在你给定的代码示例中，我没有看到任何巨大的好处。