Making distinctions between different kinds of JSF managed-beans

JSF has a simple Inversion-of-Control (IoC) container called the JSF Managed Bean Facility (MBF). Although it has a verbose XML syntax, and is not as robust as the Spring BeanFactory, PicoContainer, or the JBoss Microcontainer, the MBF does have the basics of an IoC container, and offers features like dependency injection.

When a POJO is managed by the JSF MBF, it is typically referred to as a managed-bean. But if you're going to create a maintainable JSF webapp/portlet, it is necessary to distinguish between different kinds of managed-beans. This practice will also preserve the clean separation of concerns that JSF provides by implementing the Model-View-Controller (MVC) design pattern:

Managed-Bean Type	Nickname	Typical Scope
Model Managed-Bean	model-bean	session
Description: This type of managed-bean participates in the "Model" concern of the MVC design pattern. When you see the word "model" -- think DATA. A JSF model-bean should be a POJO that follows the JavaBean design pattern with getters/setters encapsulating properties. The most common use case for a model bean is to be a database entity, or to simply represent a set of rows from the result set of a database query.
Backing Managed-Bean	backing-bean	request
Description: This type of managed-bean participates in the "View" concern of the MVC design pattern. The purpose of a backing-bean is to support UI logic, and has a 1::1 relationship with a JSF view, or a JSF form in a Facelet composition. Although it typically has JavaBean-style properties with associated getters/setters, these are properties of the View -- not of the underlying application data model. JSF backing-beans may also have JSF actionListener and valueChangeListener methods.
Controller Managed-Bean	controller-bean	request
Description: This type of managed-bean participates in the "Controller" concern of the MVC design pattern. The purpose of a controller bean is to execute some kind of business logic and return a navigation outcome to the JSF navigation-handler. JSF controller-beans typically have JSF action methods (and not actionListener methods).
Support Managed-Bean	support-bean	session / application
Description: This type of bean "supports" one or more views in the "View" concern of the MVC design pattern. The typical use case is supplying an ArrayList<SelectItem> to JSF h:selectOneMenu drop-down lists that appear in more than one JSF view. If the data in the dropdown lists is particular to the user, then the bean would be kept in session scope. However, if the data applies to all users (such as a dropdown lists of provinces), then the bean would be kept in application scope, so that it can be cached for all users.
Utility Managed-Bean	utility-bean	application
Description: This type of bean provides some type of "utility" function to one or more JSF views. A good example of this might be a FileUpload bean that can be reused in multiple web applications.

Now... One of the main benefits in making fine distinctions like this is loose coupling. What's that you ask? Well let's first take a look at an example of tight coupling, where MVC concerns can be smashed/confused into a single managed-bean:

public class ModelAndBackingAndControllerBean {

	private String fullName; // model-bean property
	private boolean privacyRendered; // backing-bean property

	// model-bean getter
	public String getFullName() {
		return fullName;
	}
	
	// model-bean setter
	public void setFullName(String fullName) {
		this.fullName = fullName;
	}

	// backing-bean getter
	public boolean isPrivacyRendered() {
		return privacyRendered;
	}

	// backing-bean setter
	public void setPrivacyRendered(boolean privacyRendered) {
		this.privacyRendered = privacyRendered;
	}

	// backing-bean actionListener for UI support logic
	public void togglePrivacySection(ActionEvent actionEvent) {
		privacyRendered = !privacyRendered;
	}

	// controller-bean business logic
	public String submit() {
		System.out.println("fullName=" + fullName);
		return "success";
	}
}

The problem here is that the bean would have to be kept in session scope because of the model-bean property. Additionally, what if we wanted to do some unit testing with mock model data? Can't do it. So in order to fix these problems, and to promote loose coupling, we would have three separate Java classes:

public class ModelBean {

	private String fullName;

	public void setFullName(String fullName) {
		this.fullName = fullName;
	}

	public String getFullName() {
		return fullName;
	}
}

public class BackingBean {

	private boolean privacyRendered;

	public void setPrivacyRendered(boolean privacyRendered) {
		this.privacyRendered = privacyRendered;
	}

	public boolean isPrivacyRendered() {
		return privacyRendered;
	}

	public void togglePrivacySection(ActionEvent actionEvent) {
		privacyRendered = !privacyRendered;
	}

}

public class ControllerBean {

	private ModelBean modelBean;
	
	public ModelBean getModelBean() {
		return modelBean;
	}

	public void setModelBean(ModelBean modelBean) {
		// Dependency injected from the JSF managed-bean facility
		this.modelBean = modelBean;
	}

	public String submit() {
    	System.out.println("fullName=" + getModelBean().getFullName());
        return "success";
    }

}

Now that the beans are found in different classes, they can all be kept in their appropriate scopes. The model-bean can be kept in session scope, and the backing-bean and controller-bean can be kept in request scope, thus saving memory resources on the server.

Finally, we can use the dependency injection features of the JSF MBF in order to inject the model-bean into the controller-bean. This can be seen in the following WEB-INF/faces-config.xml example, where the #{modelBean} Expression Language (EL) binding is used:

<?xml version="1.0" encoding="UTF-8"?>
<faces-config xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd"
	version="1.2">
	<managed-bean>
		<managed-bean-name>modelBean</managed-bean-name>
		<managed-bean-class>myproject.ModelBean</managed-bean-class>
		<managed-bean-scope>session</managed-bean-scope>
	</managed-bean>
	<managed-bean>
		<managed-bean-name>backingBean</managed-bean-name>
		<managed-bean-class>myproject.BackingBean</managed-bean-class>
		<managed-bean-scope>request</managed-bean-scope>
	</managed-bean>
	<managed-bean>
		<managed-bean-name>controllerBean</managed-bean-name>
		<managed-bean-class>myproject.ControllerBean</managed-bean-class>
		<managed-bean-scope>request</managed-bean-scope>
		<managed-property>
			<property-name>modelBean</property-name>
			<value>#{modelBean}</value>
		</managed-property>
	</managed-bean>
</faces-config>

1 Comment

Please sign in to comment.

Very interesting article, thanks!

Please sign in to reply.

More Blog Entries

Making new friends in India

Message Board Searching