struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Malks <>
Subject Re: ejb design
Date Mon, 01 Oct 2001 13:49:59 GMT
Hi Ali,
You may be interested in the "Composite Entity" pattern in our book "Core J2EE
Patterns". It describes  creating course-grained Entities that manage finer
grained dependent objects, which are not implemented as Entity beans, but rather
pojos (Plain Old Java Objects).

The book includes numerous other patterns that may be of interest to you if you
are using Struts in comibination with a distributed business tier, such as
EJB-based services.

Good luck,

Ali Ozoren wrote:

> hi all-
> i am pretty new at ejb and that might be a little off topic but here i go.
> instead of creating entity beans the conventional way, according to spec,
> would it be desirable to have one type of entity bean with a hashtable
> member to manipulate all the values and fields dynamically, accessing fields
> by their string names.
> class ValueObject
> {
>  String name;
>  Object value;
> }
> class BaseEntityBean
> {
>  String id;
>  Hashtable fields; //collection of ValueObjects, one row of data becomes
> "columncount" times ValueObjects.
>  setField(String name, Object value);
>  Object getField(String name);
>  String getAsXML();
>  BaseEntityBean findByPrimaryKey; //finds record, fills the "fields"
> variable using ResultSetMetaData
> }
> so for each different type of entity beans, we can inherit from
> BaseEntityBean, to create for instance AccountEntityBean that knows from
> which table it's going to get values.
> one obvious advantage is simplicity. one doesn't have to code setters and
> getters for all fields. another one would be addition of "custom" fields by
> the user later on. when he does that custom fields would be equal to what's
> already defined in the bean. hence no different way to handle custom fields.
> then again, obvious disadvantage is speed. instantiating the ValueObjects
> and filling the hashtable takes more time. also, we are no longer using the
> simple types for the sake of genericity which doesn't help the speed issue
> either.
> question is whether the benefits outweigh the speed disadvantage or not.
> also, is there anything against exposing a ResultSet type from an entity
> bean?
> i appreciate any input, thanks.
> --a

Dan Malks                            Sun Java Center
Enterprise Java Architect            703.208.5794

View raw message