JSF中的最佳实践：模型，操作，获取器，导航，阶段侦听器

Question

我已经进入一个用于重构JSF实现的项目。现有代码未遵循正确的JSF标准。为此，我正在学习JSF中的所有概念（我已经动手了JSF的经验）。具体来说，我想问一下我的想法。

• 在MVC模式中，JSF中的模型组件是什么？是托管豆吗？
• 在操作方法中编写业务逻辑是个好主意吗？我已经看到了用动作方法编写的数百行内容。
• 您认为我们可以在getter方法中编写任何逻辑吗？在JSF生命周期中，getter或setter调用了多少次。
• 编写faces-config.xml的常规方式是什么。我读过一个文档，它说这是一起编写该bean的托管bean声明和导航用例的良好实践。它将更具可读性。
• 编写相位监听器会影响响应时间。例如，我正在编写一种逻辑来解析PhaseListener中的请求参数并执行一些逻辑。有什么建议吗？

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

Answer 1

请注意，即使您标记了[icefaces]，该答案通常也适用于JSF，而不适用于IceFaces。

在MVC模式中，JSF中的模型组件是什么？ 是托管豆吗？

没错 视图是JSP /
Facelets页面。控制器是FacesServlet。有关其“如何在幕后”工作的更多详细信息，请参见此答案。

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

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

您认为我们可以在getter方法中编写任何逻辑吗？ 在JSF生命周期中，getter或setter调用了多少次。

如果 需要
在每个getter调用上执行业务逻辑，则应执行此操作（但是，在现实世界中这种情况不太可能发生，请期待疯狂的日志记录或特殊的延迟（重新）加载情况）。但是，如果每个动作，事件，请求，会话或应用程序范围仅需要执行一次业务逻辑，则肯定必须在其他位置执行它。另请参阅此答案。

多少次调用吸气剂应该是您最不用担心的。吸气剂除了返回有问题的属性外别无其他。调用输出值时，每个请求可以一次。调用输入值时，每个请求可以两次。在数据表/重复组件内部时，将调用乘以行数。在渲染的属性内时，将调用乘以6〜8倍。

编写faces-config.xml的常规方式是什么。
我读过一个文档，它说这是一起编写该bean的托管bean声明和导航用例的良好实践。它将更具可读性。

我自己很少使用导航用例，通常情况下我都没有faces- config.xml。我总是回发到同一个视图（回报null或void然后渲染/结果包括有条件地。对于页面到页面导航我不使用POST请求（其中导航的情况下是必须的），只是因为这是明明白白的坏UX（用户体验；浏览器后退按钮的行为不正常，浏览器地址栏中的URL总是落后一步，因为默认情况下它是转发，而不是重定向）和SEO（搜索引擎优化；搜索机器人不会为POST请求编制索引）。我只是使用outputlinks甚至纯HTML
<a>元素进行页面间导航。

同样，在JSF 2.0中，从技术上讲，不需要托管Bean定义和导航用例faces- config.xml。另请参阅此答案。

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

就像过早优化类别中的servlet过滤器一样。担心他们的表现通常没有任何意义。这通常每行仅额外增加一两行代码。真的没什么好担心的。当您在所有类中复制粘贴这段代码时，将会遇到更大的问题。如果您真的认为它会影响性能，请先对其进行概要分析，然后再进行讨论。