4

我应该为 JSF 中的每个表单、数据表等都有一个 bean 吗？

例如，我有一个注册表格，它只有 2 个字段和一个按钮，分别是： 昵称、密码、提交

提交这个表单应该去一个 RegistirationFormBean 还是在 UserBean 或 UserServiceBean 的某个地方？

最佳做法是什么？

谢谢你。

4

4 回答 4

4

要决定是否应该@ManagedBean专门为页面的组件（例如表单、数据表）创建一个，我相信您应该考虑modularity您的设计。

您应该问自己的第一个问题是：Will the component be re-used in many pages?. 例如，在ChangePassword或等敏感页面上DeleteAccount，通常会要求用户输入当前密码以验证其身份，然后再执行任何逻辑。在这种情况下，您绝对应该拥有一个用于验证密码组件的专有 bean，以便您可以一次又一次地重复使用该组件，而不必每次都重新编码验证功能。

其次，我通常@ManagedBean用作存放所有朝着同一目标工作的相关功能的地方。这种功能分组可能非常主观。例如，我可以有一个调用bean的页面，该 bean具有创建产品的所有功能。在这种情况下，就像. 另一种方法是调用一个bean ，它具有与对象相关的所有功能（即创建、读取、更新、删除）。在这种情况下，它就像（例如，）。为了方便日后的维护和分工，我通常使用. 方法二CreateProduct.xhtmlCreateProductBean1 bean per viewProductManagerProduct1 bean for many viewsCreateProduct.xhtmlRemoveProduct.xhtml1 bean per view1 bean for many views在某些情况下也很好，但我突然想不出一个例子：P......当我得到一个好的答案时，我会更新我的答案;）。

第三，我更喜欢遵循 ​​3 层 MVC 模型，将后端逻辑与前端分离。例如，要在数据库中持久化一个新帐户，我将注入一个@EJB或一个@WebServiceRef以要求后端系统执行必要的逻辑。将来肯定对维护更加友好:)。

所以，用你的RegisterAccount例子，我会有

  • 调用 1 个 beanUserExistenceValidator以检查nickname数据库中是否存在 a。在注册期间，如果用户选择了一个，我会抛出一个错误nickname。我还可以使用这个 bean 来检查页面中是否存在用户AddFriend.xhtml。
  • 另一个 bean 调用RegistirationFormBean以捕获用户的输入并与后端对话以保存新帐户。
于 2013-04-20T07:06:15.150 回答
2

调整任何JSF情人的大脑实际上是一个非常有趣的话题，所以我无法抗拒自己，我想详细解释一下。

发明背后的一个非常有趣和重要的原因JSF是，将客户端事件连接到服务器端应用程序代码，就像任何 Swing 应用程序一样，并显式地摆脱了请求和响应对象的处理。像任何 Swing 应用程序一样，我们现在可以简单地将任何客户端事件（例如，按钮单击）与一些服务器端代码绑定以处理该事件，而无需担心编写 Web 应用程序的事实和复杂性。

因此，在设计任何使用 JSF 的 Web 应用程序时，设计人员可以像设计事件驱动的 Swing 应用程序一样轻松地关注用户体验。因此，您可以设计视图页面并识别事件以执行任务并在视图之间导航。最后，您编写一些要在这些事件中执行的服务器端代码，以完成您想要的工作。这些服务器端代码驻留在您的托管 bean 中。

如果我们根据类型职责进行分类，托管 bean 有以下几种类型：

  • 模型托管豆
  • 支持托管 Bean
  • 控制器托管豆
  • 支持托管豆
  • 实用托管 Bean

您将在本文中找到每种类型的详细信息。

您的问题是，如何分配Controller Managed-Bean. 在分配此类责任时，需要考虑几个问题：

  1. 要做的任务的复杂性。
  2. 它的可重用性。
  3. 责任方面的模块化（要做的工作类型）。
  4. 从业务角度看模块化。
  5. 责任脱钩。等等

您可以将您的系统设计为使用一个单一的用于您的简单CURD操作的controller所有视图。但是，如果您需要在单个操作中处理多个复杂事务，那么将操作分离为多个，将是一个更好的设计。虽然您的注册过程非常简单，但您应该使用单独的来处理任务。因为将任何任务放在同一个托管 bean 中并不是一个好主意，这既不简单，也不够相关，无法与任务“注册”一起驻留。我认为这结束了您的查询！modelcreatecontrollerscontroller

于 2013-04-30T19:50:38.800 回答
0

在类似的情况下，我总是有一个UserManagedBean处理用户相关操作的，例如登录，注册，更改密码等......
为了处理这些操作，我在对应UserManagedBean的类型User（或任何类名）中放置了一个属性与用户相关的持久化数据（通常在数据库表用户中）。
在您的情况下nickname，并且password是User类的属性。至于submit它将调用一个方法UserManagedBean来验证用户： 

<h:inputText value="#{userManagedBean.user.nickname}"/>
<h:inputSecret value="#{userManagedBean.user.password}"/>
<h:commandButton value="Login" action="#{userManagedBean.loginUser}"/>

当然，该loginUser方法将调用对服务层的调用，该调用将调用 DAO 层来检查数据库（或其他存储）的凭据。
如果登录成功，我们的托管 bean 中的用户属性（应该是会话范围的）将使用来自 DB 的返回对象进行初始化。

于 2013-04-20T01:06:45.393 回答
0

您应该分别使用数据传输对象 bean 和域 bean 用于 ui 提交和数据库中的持久性。使用控制器类，处理您的 ui jsf 提交数据并创建一个干净的域 bean 并使用它来持久化。

如果可能，最佳实践应始终将流程/实体解耦。此外，您的 dto bean 可能具有附件和比域 bean 更多的数据，您可能出于多种目的需要这些数据。

于 2013-04-19T23:56:02.583 回答