JSF中的最佳实践：模型，操作，getter，导航，phaselisteners [英] Best practices in JSF: model, actions, getters, navigation, phaselisteners

问题描述

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

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


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


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


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


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

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

解决方案

^{请注意即使你标记了 [icefaces] ，这个答案一般适用于JSF，而不适用于IceFaces。}

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

这是正确的。 View是JSP / Facelets页面。 Controller是 FacesServlet 。有关其工作原理的详细信息，请参阅此答案。

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

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

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

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

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

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

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

另外，在JSF 2.0中，技术上不需要中的托管bean定义和导航案例faces-config.xml 。另见这个答案。

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

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

I have got into a project for re factoring of JSF implementation. The existing code is not followied the proper JSF standards. To achieve that I am learning all the concepts in JSF ( I already have hands on experiance with JSF). To be specific I would like to ask questions what I have in mind.

• In the MVC pattern, what is model component in the JSF? Is it the Managed Bean?
• Is it good idea to write the business logic in the action methods? I have seen hundreds of lines written in action methods.
• Do you think that we can write any logic in the getter methods?. How many times getter or setter called in the JSF lifecycle.
• What is the conventional way of writing the faces-config.xml. I have read in one document that it says good practice to write the managed bean declaration and navigation case for that bean together. It will be more readable.
• Writng the phase listener would affect the response time. For example, I am writing a logic to parse the request parameter in the PhaseListener and doing some logic. Is there any advice on this?

Please answer the above questions. If I am clear with the answer then I will come up with some more questions.

解决方案

^{Note that even though you tagged [icefaces], this answer applies on JSF in general, not on IceFaces.}

In the MVC pattern, what is model component in the JSF? Is it the Managed Bean?

That's correct. The View is the JSP/Facelets page. The Controller is the FacesServlet. For more detail about how it works "under the covers" see also this answer.

Is it good idea to write the business logic in the action methods? I have seen hundreds of lines written in action methods.

You can also delegate the call to a business service like an EJB. This way you can abstract the business details away. In "simple" applications it does usually not harm to leave that part away and do everything in the managed bean. However, once you comes to a point you'd like to change the business logic (e.g. for a different customer or for demo purposes, etc), then having a service would be more handy so that you don't need to change the managed beans but you just need to write another implementation class of a certain business interface.

Do you think that we can write any logic in the getter methods?. How many times getter or setter called in the JSF lifecycle.

If the business logic needs to be executed on every getter call, then do so (this is however very unlikely in real world, expect for insane logging or special lazy (re)loading cases). But if the business logic needs to be executed only once per action, event, request, session or application scope, it has definitely got to be executed elsewhere. See also this answer.

How many times a getter is called should be your least concern. The getter should do nothing else than returning the property in question. When called in output value, it can be once per request. When called in input value, it can be twice per request. When inside a datatable/repeat component, multiply the calls with amount of rows. When inside the rendered attribtue, multiply the calls with 6~8 times.

What is the conventional way of writing the faces-config.xml. I have read in one document that it says good practice to write the managed bean declaration and navigation case for that bean together. It will be more readable.

I myself use very seldom navigation cases, usually there are none in my faces-config.xml. I always post back to the same view (return null or void and then render/include the result conditionally. For page-to-page navigation I don't use POST requests (for which navigation cases are mandatory) simply because that's plain bad for UX (User eXperience; browser back button doesn't behave as it should and URL's in browser address bar are always one step behind because it are by default forwards, not redirects) and SEO (Search Engine Optimization; searchbots doesn't index POST requests). I just use outputlinks or even plain HTML <a> elements for page-to-page navigation.

Also, in JSF 2.0 there's technically no need for managed bean definitions and navigation cases in faces-config.xml. See also this answer.

Writng the phase listener would affect the response time. For example, I am writing a logic to parse the request parameter in the PhaseListener and doing some logic. Is there any advice on this?

This falls like as with servlet filters in the premature optimization category. Worrying about their performance makes usually no sense. This is per saldo usually only one or two lines of code extra. Really nothing to worry about. You would have much bigger problems when you copypaste that piece of code over all classes. If you really think that it costs performance, first profile it and then we can talk about it.

这篇关于JSF中的最佳实践：模型，操作，getter，导航，phaselisteners的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！