*
The moose likes JSF and the fly likes The granularity of JSF beans Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » JSF
Bookmark "The granularity of JSF beans" Watch "The granularity of JSF beans" New topic
Author

The granularity of JSF beans

Yi Chen
Greenhorn

Joined: Apr 28, 2006
Posts: 27
Hi all,

I am very new to JSF. I have a high level question here. What's the granularity of JSF beans? What I mean is that what should a JSF bean map to? A page? a form? or a group of pages related to a use case? etc? Usually, how should we decide what should be encapsulated into a bean?

Thanks in advance for your response.

Thanks,

Yi
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16101
    
  21

A JSF bean is basically the Model part of a Model/View/Controller setup. It stands between the UI and the business parts of the application. Because of this, it typically partakes of the natures of both MVC model and of a business object.

The View of a JSF app is typically some form of JSP. And just as in any good MVC setup, the View can be compounded as a collections of sub-views, each of which references its own model. Each sub-view references model data in a single backing bean, but not all sub-views need to be referencing the same bean. It's not uncommon for multiple pages in a workflow sequence to use a single model object in common as a means of communication between the views and to build up data for the business layer to use, but, as I said, the other way around is also useful, so it can be a Many-to-Many relationship.

How you do it is mostly a matter of what works best for the particular functions you want to support. There's no one-size-fits-all answer. In fact, you may decide to refactor as the app shapes itself.


Customer surveys are for companies who didn't pay proper attention to begin with.
Yi Chen
Greenhorn

Joined: Apr 28, 2006
Posts: 27
Thank you very much for your elaboration! It's very helpful!
Rahul Mishra
Ranch Hand

Joined: Jan 22, 2006
Posts: 211
I agree with what Tim Says.

Specifications like JSF have attempted to make the domain model richer. A JSF backing bean is just a simple java object with data and behavior. Typically when you build an application, for any meaningful enterprise application, the intent is to display persisted data or to persist the data captured from the UI forms.

For long with frameworks like Struts 1, you have had to copy data across layers(from form beans to model objects), JSF makes it redundant.

So, to answer your question - Think of a backing bean as a model object which will be leveraged to depict the view, the backing bean itself can comprise other beans..

for example, the Account backing bean can have a reference to the customer backing bean which can have the first name, last name and billing address of the customer. You can use this tree like structure of of the backing beans and map it to your UI.

However, the above is not always possible to achieve all the time and real time applications tend to sway towards mapping a backing bean to a UI form (old habbits may be?)...strike a balance..begin from considering that your backing bean is a model object and tailor it to meet your UI requirements..

However, do remember that the backing bean should not just contain data but also behavior (we seem to be forgetting it these days)..

Hope it helps..


OCMJEA/SCEA, SCDJWS, SCBCD 1.3, SCJP 1.4
My SCEA experience:http://javalogue.blogspot.com/
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16101
    
  21

If you're using an ORM, you can often - but not always - present actual domain model objects as direct view models.

However, between differences in datatyping, behaviors and so forth, it's quite common to provide a fa├žade or decorator in front of the actual domain object.

Still, it beats DTOs!
 
GeeCON Prague 2014
 
subject: The granularity of JSF beans