struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christophe Marchand" <christophe.march...@labodev.com>
Subject Re: ejb design
Date Mon, 01 Oct 2001 09:59:56 GMT
Wrong idea ! EJB entity are made to "store" one and only one record or
ValueObject. findByPrimaryKey entity method is designed to retrieve one
record, depending on a primary key object. If you use only one entity class
with a hashtable, you'll have a lot of problem to solve :
1 - your primary key object will be udge to store all data from all primary
key from all value objects,
2 - your value objects wouldn't able to extend a primary key object (are be
composed with)
3 - you will be obliged to use BMP (Bean managed persistance) entity beans,
with many sql statements in, and it we'll be very difficult to maintain when
you change your data model.
4 - if you decide in the future to split your database in two ones, and then
to deploy on two different servers, you'll keep a lot of unused code in your
classes (or you'll be obliged to re-write everything, both entity beans and
client-side jndi calls...)

Your solution is technically possible, but you are goi ng to spend a lot of
nights to maintain this, for no gain...

Have a look at "Mastering EJB's" book, which is very interesting on ejb's
design considerations...

Hope this helps.

Regards

----- Original Message -----
From: "Ali Ozoren" <ozorena@home.com>
To: <struts-user@jakarta.apache.org>
Sent: Monday, October 01, 2001 4:52 AM
Subject: ejb design


> 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; file://collection of ValueObjects, one row of data
becomes
> "columncount" times ValueObjects.
>
>  setField(String name, Object value);
>  Object getField(String name);
>  String getAsXML();
>  BaseEntityBean findByPrimaryKey; file://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
>
>
>


Mime
View raw message