Alternatively you could generate the code and then you wouldn't have the
overhead of reflection at runtime.
One thing you miss with the generic approach is type-safety.
Cheers
Jay Walters
NetNumina Solutions
-----Original Message-----
From: Heiko Gottschling [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 09, 2001 8:27 AM
To: [EMAIL PROTECTED]
Subject: Please comment: Using java.lang.reflect to simplify database
access
Hi,
I have noticed that in my application I have lots of similarly structured
methods to read records from a database. For example, I have a session bean
called ProjectManager, which has methods like these:
ProjectValue getProject(int id)
TaskGroup getTaskGroup(int id)
ProjectClass getProjectClass(int id)
and so on. The implementations of these methods are very similar, they all
issue a SELECT statement and fill the value objects (which are not much more
than struct-like entities, with public fields corresponding to all columns
of
the associated database table) with the obtained results, like
resultSet = statement.executeQuery("SELECT name, creationDate [...] FROM
Project WHERE id=" + id);
projectValue.name = resultSet.getString("name");
projectValue.creationDate = resultSet.getDate("creationDate");
Now, here is what I thought of, and I'd like to hear your comments on this:
I want to create a SessionBean, let's call it DatabaseUtil, with a method
like:
Object getRecord(String tableName, int id)
this method would use the java reflection package to look up a class named
<tableName>Value, retrieve the names of all of its public fields, construct
a
SELECT statement from these field names, and construct a new
<tableName>Value
object from the returned result set.
This approach would save a lot of redundant coding. Can you think of any
potential drawbacks? What about performance overhead when using reflection?
(I gather J2EE uses it all the time anyway)?
thx
Heiko
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
