JSF project structure

[Meghna Bhardwaj]

I am writing a simple enough program using JSF, and I need some advice about how to go about it. I have a jsp which takes a unique ID and has to find out if the ID exists in 3 different databases. If it does it should display a message telling user, where it exists, otherwise it should give the user option to add the ID to a particular database.

I have the jsp page which has a text field for the input ID and I have a button called "Submit" which should trigger the process of querying the db to see where the ID exists. My question is, how to structure this project, in terms of front end, middle teir and db layer. I have a JSP page, when the user clicks the Submit button, I have a listener in the managed bean which gets executed. I have also read up that the listeners can either be a managed bean or a separate class. Should I have a separate class which is the listener? If so, should it be a Servlet mapping in the web.xml file, so all request get forwarded to this class. Should there then be a separate DAO class where the actual query gets executed. We are using hibernate as well.

I would jsut like to hear people comments about how many classes there should be and how a particular ID Check will flow through the program from JSP->Servlet(?)-> DAO and then back to the same jsp. There is only JSP , there will be no other navigation pages.

Any direction will be much appreciated.

[Tim Holloway]

This is the JSF Forum. It sounds like you should have posted in the JSP Forum. It makes a very large difference on what components you'd use to construct a project!

[Meghna Bhardwaj]

I believe I am on the right forum, my project is JSF, but since the actual pages are .jsp files that is why i have mentioned jsp.

[Tim Holloway]

It's not what you name them, it's what they do that counts. Technically, they're JSF Views, as part of JSF's Model/View/Controller architecture.

JSF actually works best if you have the front end (View/JSF/"JSP"), View Model (backing bean), business layer, and then persistence layer (typically Data Services/DAO's and Domain Model). Simple projects may collapse some of these, but it's good for complex projects, because even though the number of total components is greater, each component is simpler and easier to understand/maintain.

In a case like yours, I'd make a JSF view with the data entry box and a submit button (lookup command button). This would then cause navigation to either a display page (ID found) or an entry page with the list of eligible targets and a submit button (assignment command button). The backing bean would present properties for the ID value and the selected database identifier and its list datamodel. It would also contain the action processors for the lookup and assignment command buttons.

A separate business bean could take care of fanning out to the different data persistence objects. Or, as I mentioned, you could collapse the business logic into the backing bean and save having an extra class at the expense of losing some per-component simplicity and portability/reusability.

BTW, sorry for being sloppy there. I'm using the words "view" and "page" interchangeably.