Backing bean organization in JSF

4
votes

I have been thinking about this for a while now and have yet to come up with a best practice for how to organize my beans/classes in a JSF project for the presentation tier. Obviously there are many factors that come into play, but I would like to discuss. Here is my current line of thought:

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

Request scoped BackingBean:

  • View related stuff (save status, render logic, etc.). Stuff that is only needed in one request
  • Actions, action listeners, and value change listeners. If they are applicable to more than one view, they can be separated into their own file.

Session scoped BackingBean:

  • Anything that needs to remain around longer than one request. Database data, SelectItems, etc.
  • This bean is injected into the request bean, and stores instances of any data objects

Data Objects:

  • It doesn't seem to make sense to make the data objects into beans, so they are stored separately. This would be things like User, Book, Car, any object that you are going to display on the page. The object can contain view helper methods as well such as getFormattedName(), etc.

DAO:

  • A non-bean object that handles all interaction with the business logic tier. It loads the data bean and prepares submits, etc. I usually make this a class of public static methods.

Converters, Validators:

  • Separate files

This seems to be all that is needed in your average JSF application. I have read through this: http://java.dzone.com/articles/making-distinctions-between, as well the replies here: JSF backing bean structure (best practices), but I never felt like we got a complete picture. BalusC's response was helpful, but didn't seem to quite cover a full app. Let me know your thoughts!

1
jsfarchitecturejsf-1.2managed-beanbacking-beans
It wasn't me who answered that question. Even more, I personally disagree that answer. See also stackoverflow.com/questions/7223055/… To supplement this answer, you may find the following answer helpful: stackoverflow.com/questions/7031885/… True, JSF 2.x, but the same principles apply on JSF 1.x as good. - BalusC
That first link is what I meant to link to. I had a little trouble following your reply there though. If I understood you correctly, the model bean is similar to my data objects, and the controller/managed bean you are saying should be one bean, similar to my backingbean, although I split it up into two in order to minimize the amount of session data. Is that accurate? - bhouse

1 Answers

1
votes

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

  1. I would take your DAO layer and split it into two seperate layers, one pure DAO layer that merely is responsible from fetching data from various sources (Eg. database calls, web service calls, file reads, etc...). I would then have a Business Logic layer that contains passthroughs to DAO calls as well as any additional calculations, algorithms, or other general business logic that isn't specific to any one JSF view.

  2. In the MVC pattern, your ManagedBean plays the role of the Controller, and as such should also be the repository for Presentation Logic (logic that is specific to manipulating the view or interacting between various View components). It will also tie your business logic into the event behavior as well.

  3. I would not use public static methods for your Business Logic or DAO layer. This doesn't lend itself well to automated unit tests and prevents your app from utilizing Dependency Injection frameworks like CDI or Spring. Instead create an interface for your BO's and DAO's and then an implementation class for this.

  4. On that note, utilize a Dependency Injection Framework like CDI or Spring :) It will allow you to automatically inject Business Logic objects or DAO's into your ManagedBeans as well as your unit tests. It will also allow for you to swap implementations or DAO's without any coupling to code in other layers of your application.