Arti, This mailing list is specific to the ADF Faces incubator; questions like this should go to more general JSF lists, like the MyFaces user list.
Regards, Adam Winer On 4/10/06, arti <[EMAIL PROTECTED]> wrote: > Hi > > 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 > component-bean? > > Thanks, > Arti > >
