4

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!

Community
  • 1
  • 1
bhouse
  • 115
  • 2
  • 7
  • 1
    It wasn't me who answered that question. Even more, I personally disagree that answer. See also http://stackoverflow.com/questions/7223055/distinction-between-different-types-of-managed-beans To supplement this answer, you may find the following answer helpful: http://stackoverflow.com/questions/7031885/how-to-choose-the-right-bean-scope True, JSF 2.x, but the same principles apply on JSF 1.x as good. – BalusC Sep 13 '12 at 18:49
  • 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 Sep 13 '12 at 20:17

1 Answers1

1

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.

maple_shaft
  • 10,435
  • 6
  • 46
  • 74
  • Thanks for the reply! I think I may not have been clear in my post, but I have broken the project into three tiers. So my post was only about the presentation tier. There is also a Spring Framework built 'business' tier that does the database calls and stuff like that. My "DAO" is just a class that basically takes the Business Objects and maps them to my presentation layer data objects. And then the other way around when submitting back to the business layer. – bhouse Sep 13 '12 at 20:20
  • As for point number 2: I agree that the backing bean should play the role of controller, and that is what my request scoped bean would do. It can also provide view manipulation or interaction as you said. – bhouse Sep 13 '12 at 20:23
  • then what exactly is playing the role of Model in JSF? – Chaitanya Gudala Oct 02 '12 at 08:38
  • @KrsnaChaitanya Well if we are talking about the Model then we also must include the ViewModel. The ViewModel would also be the Managed Bean, however the persisted Model can be as simple as POJO's, Hibernate, or JPA entities. – maple_shaft Oct 02 '12 at 10:59
  • @maple_shaft what if we really want to seperate view and model in JSF.Generally we tend to use Managed Bean, as both View and Model which means that there is clear violation of MVC architecture inspite of using JSF.Then how can one say JSF ensures MVC architecture in the project ? – Chaitanya Gudala Oct 03 '12 at 05:21