exposing your database field names out of your Entity beans is a bad idea, as
it increases the coupling between your clients and database. You can't refactor
your schema without affecting your client code!
This is a common error made by people new to EJB but with a lot of RDBMS/RAD
experience. You have to stop thinking about your entity beans as an eqivalent
to tables in yoru database (it's fine if they match because of synergy between
the class model and the physical storage, but don't let your database drive
you class model).
-----Original Message-----
From: Ali Ozoren [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 02, 2001 14:23
To: [EMAIL PROTECTED]; Christophe Marchand
Subject: RE: ejb design
Well- I think I didn't explain myself well enough. I try again between the
lines.
-----Original Message-----
From: Christophe Marchand [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 01, 2001 6:00 AM
To: [EMAIL PROTECTED]
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
