请注意，即使您标记了[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过滤器一样。担心他们的表现通常没有任何意义。这通常每行仅额外增加一两行代码。真的没什么好担心的。当您在所有类中复制粘贴这段代码时，将会遇到更大的问题。如果您真的认为它会影响性能，请先对其进行概要分析，然后再进行讨论。
