incubator-adffaces-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "arti" <>
Subject Managed Bean Best Practices
Date Mon, 10 Apr 2006 16:34:56 GMT

Are there any best practices for using Managed Beans?

We plan to use our own custom-built JSF components. Need to understand
how to design backing beans for performance/effort optimization.
For example :

1. How to make managed beans thread-safe for concurrent requests,
without compromising on efficiency/speed?

2. How to enforce the J2EE security with managed-beans?

3. How to decide the scope of these beans to ensure minimal data-storage
in session?

4. How to decide the granularity at which a managed-bean should be used
for example :

4.1 One bean-per-component
    Advantages :
	  a) if complex components require special
data-holding/processing/event-handling capabilities from bean 
	    (e.g. datagrid model,tree model,menu model)
    Problems :
	- with multiple components in a page/form 
	   a) it becomes tedious to debug/change/track which bean serves
which component 
	   b) if session scope is required, too many beans will be
cached in session
	   c) unnecessarily too many beans will be created on server (=
n pages * m components-per-page)
	   d) unnecessarily increases the length of faces-config.xml

4.2 One bean-per-form 
    Advantages :
	   a) in multi-form web pages, to ensure the functional
behaviour of each form is separate/modular in its own bean. 
	   b) each managed-bean would map to specific/meaningful
functionality/user-interaction in use-case.

    Problems :
	- if form includes complex components (datagrid/tree/menu)
requiring a specialised bean class, then 
	  a) either one of the specialized bean has to be augmented with
additional logic to handle data/events for all other components within
the form
	    (Not good, as it mixes-up the responsibilities of
component-specific-beans, and the bean may no more be reusable in
another form)

	  b) or without using component-specific beans, only single form
bean should handle the data/events for all components in the form?
	    (Neither good, since if a complex tree-compoent is reused in
multiple forms, then the logic to handle data/events for such a
component will be repeated in those many form-specific managed beans) 

4.3 One bean-per-page 
	Advantages :
	  a) seems more modular/meaningful way - since a page would map
to some feature within the use-case
	  b) bean will contain only behaviour which is relevent for the
associated page/function within use-case
	Problems :
	  a) in multi-form pages, can single bean handle data/events for
multiple forms?
  	  b) if page uses complex component (e.g datagrid, tree) that
needs its own bean - how does page-bean exchange data with


View raw message