struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ali Ozoren" <ozor...@home.com>
Subject RE: ejb design
Date Tue, 02 Oct 2001 04:22:32 GMT
Well- I think I didn't explain myself well enough. I try again between the
lines.

-----Original Message-----
From: Christophe Marchand [mailto:christophe.marchand@labodev.com]
Sent: Monday, October 01, 2001 6:00 AM
To: struts-user@jakarta.apache.org
Subject: Re: ejb design


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)

--- I am planning to return only one row from the db. But instead of
attaching each column's value into a separate member variable, I am
proposing to enter values into a hashtable. If there is more than one row in
the resultset it can easily throw a TooManyRows exception, which should
never happen.

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.

--- I will use BMP but code won't change with structural changes since it
builds the hashtable by looking at the specified table for that bean. So as
soon as you add a field to table, it is ready to be accessed using
getValue("newFieldName") call.

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...

--- My solution is supposed to accomplish exact opposite. Less coding, less
maintenance.

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

--- I have that. Ed Roman's. Excellent book IMHO.

Thanks for the input,
--a


Mime
View raw message