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.有关它如何工作的更多细节"在幕后"也参见这个答案.

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

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

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

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

调用吸气剂的次数应该是您最不关心的问题.除了返回有问题的属性之外,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过滤器一样.担心他们的表现通常没有意义.这通常只需要一两行代码.真的没什么值得担心的.当你在所有类中复制那段代码时,你会遇到更大的问题.如果你真的认为它需要性能,首先对它进行分析,然后我们就可以讨论它.