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