From Backing Bean to Managed Bean

What is a backing bean? Getting a consistent answer can be harder than you might think. For example, the NetBeans JSF tutorial claims that the two terms are synonyms. And NetBeans had its origin at Sun, so they ought to know, right? On the other hand, the official Java EE 5 Tutorial says that a backing bean “is a JavaServer Faces managed bean that is associated with the UI components used in a particular page.” That suggests that backing beans are a proper subclass of managed beans. And that’s straight from the horse’s mouth, at

I think that the distinction made by the Java EE tutorial–that a backing bean is a particular sort of managed bean distinguished by its association with a particular page’s components–is a very useful one. But the tutorial also states that “A typical JavaServer Faces application couples a backing bean with each page in the application.” And that is where we part company.

It’s not that backing beans don’t have their place. Sometimes you’ll have a bit of functionality so specific to a page that it really belongs in a backing bean for that page–for example, to retrieve data so specific you know it will be on one page only (although if you’re using ADF, you should be relying on the ADF data binding layer to retrieve most of your data for you), or to store bookkeeping data that’s only used for null navigation cases. Or you might need to programmatically customize a component that will be used on one page only.

But in most applications–particularly ADF applications, where your primary data access is not handled by managed beans at all–backing beans should be the exception, not the rule. There should not, in general, be anything like a one-to-one mapping between your pages and your managed beans. There are three main reasons for this.

Backing Beans Are not Reusable Unless your Pages Are

In your typical application, pages aren’t entirely unique from top to bottom. There will be something–above and beyond a CSS style–that will be used across multiple pages, and possibly even across multiple applications. This might be something nice and literal, like a heading; in that case, you can just pop the value into a resource bundle and be done with it. On the other hand, it might be something dynamic, like a timestamp (these are pretty useful, actually–tuck it into a corner of a page, and when a customer calls with an error, your support tech can ask them for the timestamp and match it up with the application log).

Now, in ADF 11g, you’d be likely to put controls shared across pages in their own JSF page fragment, and use them in regions on other pages (or as part of bounded task flows that are used in such regions), so the moral here could simply be to associate backing beans with each fragment, rather than each page. Something similar might apply in a non-ADF framework such as Tiles. But if you’re working in any other environment (including ADF 10g), the non-reusability of managed beans intimately tied to a single page is a real issue.

But wait a moment–why can’t we use inheritance to simply factor common code from backing beans out into a shared superclass? Well, you can, but this approach has its limitations, such as the fact that each class can only inherit from one class hierarchy, so this plan doesn’t let you mix-and-match shared functionality. There are design patterns that solve this, of course, generally by factoring shared code out into object members rather than superclasses, but at that point, you might as well make the external objects into managed beans. Those won’t be backing beans (because they specifically contain functionality not related to any particular page), so we’re back to our broad recommendation.

Backing Beans are Request-Scoped

This one’s pretty obvious, and it’s one place where you dosee managed beans that are not backing beans in many applications. Sometimes, of course, you need to store information at the session or even application level, and backing beans are not appropriate for that–for one thing, if you try to put page components in a session- or application-scoped bean, those components won’t be reassigned whenever the UI model is re-created, meaning that they’ll become out of sync with what’s actually being displayed.

All I want to remind people here is not to be shy to create managed beans with scope that outlasts a request. Which means not to be shy to create non-backing managed beans.

Backing Beans Are Organized Around the View

This one, on the other hand, is not obvious, but it’s one I feel very strongly about. Remember that the whole idea of JSF–of MVC Model 2 architecture in general–is to separate out rendering of data and widgets to the user (that is, the view) from handling user input (that is, the controller). Backing beans, by definition, are organized around pages, that is, view components. They’re not organized around tasks.

Which means that backing beans, if you have any, should be part of the view. If you put controller functionality (such as action methods or actionListener accessors) into a backing bean, you’re mixing your view and your controller. It’s almost like hardcoding a link into a page, rather than relying on the page flow; you’re coding “where to go next” into a piece of code intimately linked to a particular page.

If you use backing beans, whose classes are organized around view components, they should be exclusively involved in the job of the view–setting up the UI. You should put the code that provides controller functionality into bean classes that are organized around tasks, not pages.

This way of thinking requires a bit of getting into before it will seem natural. And, alas, ADF doesn’t especially help, since pageDefs, your primary access to data from either the view *or* the controller, are organized around pages. (For controller-organized beans, you might want to consider circumventing the binding container and going straight to the binding context–accessible through the EL expression “#{data}”.) But I do recommend it, both for the immediate practical benefits like reusability and for the somewhat vaguer benefits like view/controller separation, which will, ultimately, make your code easier to understand and maintain.

2 thoughts on “From Backing Bean to Managed Bean”

  1. hi…..

    I just want to know is ADF backing bean hamper the Project performance.
    Is there any Problem of using “Backing Bean” in large scale???

Leave a Reply

Your email address will not be published. Required fields are marked *