You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Bryan Field-Elliot <br...@netmeme.org> on 2001/08/28 20:00:05 UTC

Re: Performance, Reflection, and Object Creation vs. Cacheing

Thanks for the insights Ted,

Please help me if I'm misinterpreting. But looking at your code, it 
seems like your "populate" still takes a plain Bean as it's destination, 
although it can use a property set (in this case, a ResultSet) as the 
source. This reduces the proliferation of Value (or other Bean) classes 
by 50%, but not 100%. In your scenario, which set of beans still need to 
be developed as plain old beans rather than dynamic sets of properties 
(e.g. the Entity beans, the Value Objects, or the Struts Form Beans, etc?)?

Thanks,
Bryan


Ted Husted wrote:

>
>    public static void populate(Object bean,
>                                ResultSet resultSet)
>



Re: Performance, Reflection, and Object Creation vs. Cacheing

Posted by Ted Husted <hu...@apache.org>.
To close the loop, it's helpful if a JavaBean can provide a Map of
itself. This way you can do things like

BeanUtils.populate(beanTarget,beanSource.toMap()). 

So I tend to define an interface that requires that and apply it to all
my beans, regardless of role. 

One consequence is that this will populate the properties that match,
and ignore any property that doesn't, so you don't have any parity
checking between the source and target. Though, usually this is a Good
Thing. For example, you can use the same bean class for a list and for
the detail, and just leave most of the properties null when it is being
used on the list.

Bryan Field-Elliot wrote:
> 
> Thanks for the insights Ted,
> 
> Please help me if I'm misinterpreting. But looking at your code, it
> seems like your "populate" still takes a plain Bean as it's destination,
> although it can use a property set (in this case, a ResultSet) as the
> source. This reduces the proliferation of Value (or other Bean) classes
> by 50%, but not 100%. In your scenario, which set of beans still need to
> be developed as plain old beans rather than dynamic sets of properties
> (e.g. the Entity beans, the Value Objects, or the Struts Form Beans, etc?)?
> 
> Thanks,
> Bryan