struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Husted <hus...@apache.org>
Subject Re: Performance, Reflection, and Object Creation vs. Cacheing
Date Tue, 28 Aug 2001 20:11:33 GMT
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

Mime
View raw message