Evan Ireland wrote:
> Among our customers, I see two distinct requirements for CMP.
>
> (1) CMP where the customer wants persistent objects, and couldn't care at all
> where or how their data is stored. (The spec allows Java Serialization to
> be used in this case).
>
> (2) CMP where the bean's persistence must map to database schemas that already
> exist or are created by the customer (in the RDBMS case, they may sometimes
> want to be able to use SQL to access their data).
>
> Where the customer wants the latter, I believe that tools that generate BMP
> code are an essential part of the equation, since no matter how 'clever' a CMP
> code generator is, it might not be adequate to meet the customer's requirements,
> so generating BMP code that the user can then modify is very useful.
This is very true. BMP provides much more flexibility if the persistent store
already has an existing structure and data. This seems to be the case in many
projects. Actually I would say that even green field projects benefit more from BMP
with RDBMS are used then CMP because the RDB can be normalized and therefor better
able to accommodate other systems and tools (like reporting systems and data ware
housing tools). This is why I like products like CocoBase, which generates BMP
entities for RDBMS but keeps the code portable. If you can alter the beans after
they are generated its even better because you can introduce more complex behavior
that the OR tool may not have been able to generate.
--
Richard Monson-Haefel
Author of Enterprise JavaBeans
Published by O'Reilly & Associates
( http://www.monson-haefel.com )
===========================================================================
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".
