Best practices in JSF: model, actions, getters, navigation, phaselisteners

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 method开发者_运维问答s.
• 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.

---

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

I suggest this:

VIEW LAYER (consists of a mini MVC):

userForm.xhtml <-- view; the web page

UserController <-- controller; a managed bean

UserController.get/setUser <-- model; the model for the view

CONTROLLER LAYER:

UserService <-- controller; the controller that contains CRUD related business logic

UserDAO <-- persists objects to the database

User <-- the domain object that gets persisted

MODEL LAYER:

The database

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

In my example, put the business logic in the methods of the UserService. The action method of UserController doesn't do much more than call the method in the UserService, catch any exceptions and format the response for the next web page that is displayed.

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

Preferable for getter/setters to just do the getting/setting. No logic.

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 declare all of my managed beans together. And declare all of my navigation rules together.

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?

Not sure what you're doing exactly, but you shouldn't have to manually parse request parameters. JSF should inject the values of your form directly into the model of the view for you. Maybe I need more info about what you're trying to do.

Hope this helps.