The granularity of JSF beans

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?

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.

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)..