incubator-adffaces-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Winer" <awi...@gmail.com>
Subject Re: Managed Bean Best Practices
Date Mon, 10 Apr 2006 17:36:34 GMT
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 <arti@tambas.at> 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
>
>

Mime
View raw message