JSF中的最佳实践：模型，操作，getter，导航，phaselisteners

Question

我已经进入了一个重新考虑JSF实现的项目。现有代码没有遵循正确的JSF标准。为了实现这一点，我正在学习JSF中的所有概念（我已经掌握了JSF的实验）。具体来说，我想问一下我的想法。

• 在MVC模式中，JSF中的模型组件是什么？它是Managed Bean吗？
• 在动作方法中编写业务逻辑是否是个好主意？我已经看过用行动方法写的数百行。
• 您认为我们可以在getter方法中编写任何逻辑吗？在JSF生命周期中调用getter或setter的次数。
• 编写faces-config.xml的传统方法是什么？我在一个文档中读到它说好的做法是将bean的托管bean声明和导航案例一起编写。它会更具可读性。
• 写入阶段监听器会影响响应时间。例如，我正在编写一个逻辑来解析PhaseListener中的请求参数并执行一些逻辑。对此有什么建议吗？

请回答上述问题。如果我对答案很清楚，那么我会提出更多问题。

Answer 1

^{请注意，即使您标记了[icefaces]，此答案也适用于JSF，而非适用于IceFaces。}

  

在MVC模式中，JSF中的模型组件是什么？它是Managed Bean吗？

这是对的。 View是JSP / Facelets页面。控制器是FacesServlet。有关其工作原理的详细信息，请参阅this answer。

  

在动作方法中编写业务逻辑是个好主意吗？我已经看过用行动方法写的数百行。

您还可以将调用委托给像EJB这样的业务服务。这样您就可以抽象出业务细节。在“简单”的应用程序中，将该部分留下并在托管bean中执行所有操作通常不会有害。但是，一旦你想要改变业务逻辑（例如，针对不同的客户或用于演示目的等），那么拥有一个服务会更方便，因此您不需要更改托管bean，但你只需要编写某个业务接口的另一个实现类。

  

你认为我们可以在getter方法中编写任何逻辑吗？在JSF生命周期中调用getter或setter的次数。

如果业务逻辑需要在每次getter调用时执行，那么这样做（但这在现实世界中是非常不可能的，期望疯狂的日志记录或特殊的懒惰（重新）加载情况）。但是，如果每个操作，事件，请求，会话或应用程序范围只需要执行一次业务逻辑，那么它肯定必须在其他地方执行。另见this answer。

呼叫吸气器的次数应该是您最不关心的问题。除了返回有问题的属性之外，getter应该什么都不做。在输出值中调用时，每个请求可以一次。在输入值中调用时，每个请求可以两次。在数据表/重复组件内部时，将调用与行数相乘。当在渲染的属性内部时，将调用乘以6~8次。

  

编写faces-config.xml的常规方法是什么。我在一个文档中读到它说好的做法是将bean的托管bean声明和导航案例一起编写。它更具可读性。

我自己很少使用导航案例，通常我的faces-config.xml中没有。我总是回发到同一个视图（返回null或void，然后有条件地渲染/包含结果。对于页面到页面导航，我不使用POST请求（导航案例是强制性的）仅仅是因为这对用户体验很不利（用户体验;浏览器后退按钮的行为不应该如此，浏览器地址栏中的URL总是落后一步，因为它是默认转发，而不是重定向）和SEO（搜索引擎优化） ; searchbots不会对POST请求编制索引。。我只是使用outputlinks甚至纯HTML <a>元素进行页面到页面的导航。

此外，在JSF 2.0中，技术上不需要faces-config.xml中的托管bean定义和导航案例。另请参阅this answer。

  

写入阶段监听器会影响响应时间。例如，我正在编写一个逻辑来解析PhaseListener中的请求参数并执行一些逻辑。对此有什么建议吗？

这与过早优化类别中的servlet过滤器一样。担心他们的表现通常没有意义。这通常只需要一两行代码。真的没什么值得担心的。当你在所有类中复制那段代码时，你会遇到更大的问题。如果你真的认为它需要性能，首先要对其进行分析，然后我们就可以讨论它。

Answer 2

在MVC模式中，JSF中的模型组件是什么？它是Managed Bean吗？

我建议：

VIEW LAYER（由迷你MVC组成）：

userForm.xhtml＆lt; - view;网页

UserController＆lt; - controller;托管bean

UserController.get / setUser＆lt; - model;视图的模型

控制器层：

UserService＆lt; - controller;包含CRUD相关业务逻辑的控制器

UserDAO＆lt; - 将对象持久保存到数据库

用户＆lt; - 持久存在的域对象

MODEL LAYER：

数据库

在动作方法中编写业务逻辑是个好主意吗？我已经看过用行动方法写的数百行。

在我的示例中，将业务逻辑放在UserService的方法中。 UserController的action方法除了调用UserService中的方法，捕获任何异常并格式化显示的下一个Web页面的响应之外没有什么作用。

你认为我们可以在getter方法中编写任何逻辑吗？在JSF生命周期中调用getter或setter的次数。

优先选择getter / setter来获取/设置。没有逻辑。

编写faces-config.xml的常规方法是什么。我在一个文档中读到它说好的做法是将bean的托管bean声明和导航案例一起编写。它更具可读性。

我将所有托管bean声明在一起。并一起声明我的所有导航规则。

写入阶段监听器会影响响应时间。例如，我正在编写一个逻辑来解析PhaseListener中的请求参数并执行一些逻辑。对此有什么建议吗？

不确定您正在做什么，但您不必手动解析请求参数。 JSF应该将表单的值直接注入到视图模型中。也许我需要更多关于你想要做什么的信息。

希望这有帮助。