Hi,
> 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.
I have a quite number of tables with a very simple structure, e.g. a
TeamMemberType table (like free lance, regular etc.), for which there is no
need for a more complex mapping. For the complex ones I do use BMP.
If the DB structure is changed, everything I have to do is change the
attributes of my value class, instead of re-writing all SQL statements, which
would have been required before.
As for persistent fields, the value classes are specifically designed to have
exactly one public field for every column of the table (as I said they are
not much more than structs, without much functionality).
> 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..
Good question. I'm quite new to this EJB stuff, and I've always wondered what
CMP is good for ;-)
One reason I don't use CMP is that I think it would be an overkill to model
all these 'trivial' tables rows as entity beans. As the blueprint states,
entity beans should be coarse-grained business objects with complex behavior,
which would not be the case here.
cu
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".
