Support for bean organizations in JSF

Question

I have been thinking about this for a long time and have not yet figured out how to organize my beans / classes in a JSF project for presentation level. Obviously, many factors come into play, but I would like to discuss. Here is my current thought:

Consider the base JSF (still stuck on JSF 1.xx here, unfortunately) an application that contains a view page (view data) and an edit page (add, update, delete data). Here is how I could organize a project:

BackingBean Scope Request:

• View related materials (saving status, visualization of logic, etc.). Material that is required only on one request.
• Actions, action listeners, and value change listeners. If applicable to multiple views, they can be split into their own file.

BackingBean session coverage:

• All that should remain around more than one request. Database data, SelectItems, etc.
• This bean is entered into the bean request and stores instances of any data objects

Data Objects:

• It seems there is no point in making data objects in beans, so they are stored separately. It will be such things as User, Book, Car, any object that you are going to display on the page. An object may also contain helper presentation methods, such as getFormattedName (), etc.

DAO:

• A bean that handles all interactions with the business logic layer. It loads bean data and prepares views, etc. I usually do this with a class of public static methods.

Converters, validators:

• Single files

This seems to be all that is needed in your average JSF application. I read this: http://java.dzone.com/articles/making-distinctions-between , and also the answers here: Support for the JSF bean structure (best practices) , but I never felt like we had a complete picture. BalusC's answer was helpful, but didn't seem to cover the full application. Let me know your thoughts!

Answer 1

I think you are on the right track at all, however I would do a few things differently:

• I would take your DAO layer and split it into two separate layers, one pure DAO layer, which is simply responsible for fetching data from different sources (for example, database calls, web service calls, reading files, etc ...). Then I would have a business logic layer containing forwarders for DAO calls, as well as any additional computations, algorithms, or other general business logic that is not specific to any one JSF representation.

• In the MVC template, your ManagedBean plays the role of the Controller, and as such there should also be a repository for Presentation Logic (logic specific to controlling the presentation or interaction between the various components of the View). It will also link your business logic to event behavior.

• I would not use public static methods for your business logic or DAO level. This does not justify automated unit tests and does not allow your application to use Injection Dependency frameworks such as CDI or Spring. Instead, create an interface for your BO and DAO, and then for this implementation class.

• In this post, use an Injection Dependency platform such as CDI or Spring :). This will allow you to automatically enter Business Logic or DAO objects in your ManagedBeans, as well as your unit tests. It will also allow you to perform replacements or DAOs without any connection with the code in other layers of your application.