I do not know if it is relevant in ur case, but have you considered the fact
that such an approach binds ur bean very tightly with the database tables.
Each and every attribute of the bean maps to exactly the same fields in the
table. What about one bean mapping to multiple tables. Or what if, lets say,
the bean design or the db structure changes tomorrow. What about non
persistent fields.
If your application requires for a clean and complete mapping, say for 80%
of the beans, then a util is a good idea. For others you may decide not to
use the utility and write customised code.
Another thing : if the mapping is so clean , then why not go for CMP..
----- Original Message -----
From: David M. Karr <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 09, 2001 9:16 PM
Subject: Re: Please comment: Using java.lang.reflect to simplify database
access
> >>>>> "Heiko" == Heiko Gottschling <[EMAIL PROTECTED]> writes:
>
> Heiko> Now, here is what I thought of, and I'd like to hear your
comments on this:
>
> Heiko> I want to create a SessionBean, let's call it DatabaseUtil, with
a method
> Heiko> like:
>
> Heiko> Object getRecord(String tableName, int id)
>
> Heiko> this method would use the java reflection package to look up a
class named
> Heiko> <tableName>Value, retrieve the names of all of its public fields,
construct a
> Heiko> SELECT statement from these field names, and construct a new
<tableName>Value
> Heiko> object from the returned result set.
>
> Heiko> This approach would save a lot of redundant coding. Can you think
of any
> Heiko> potential drawbacks? What about performance overhead when using
reflection?
> Heiko> (I gather J2EE uses it all the time anyway)?
>
> Assuming a usual situation where you will access objects of any
> particular class a significant number of times, then cache most of the
> reflection results by class. In particular, you could cache the
> PreparedStatement and the list of Field objects.
>
> --
> ===================================================================
> David M. Karr ; w:(425)487-8312 ; TCSI & Best Consulting
> [EMAIL PROTECTED] ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004)
>
>
===========================================================================
> 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".
