I agree, except w/regard to blobs. If you turn the child objects into binary
blobs, other clients of your database (report writers and such) are not
going to be happy.
<vendor>
Much better to use an OR framework that support beans that have dependent
object children. If your EJB server can't handle this, get another one.
Also, Cocobase provides a solution that can be used with several possible
EJB servers.
</vendor>
-Chris.
> -----Original Message-----
> From: Jouni Juutinen [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, February 25, 2000 3:02 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Dependent classes
>
> Interesting question (again) is how one handles the persistence of
> dependent
> objects. I quess there are at least two options:
> 1. Make dependents as regular Java classes (e.g. Address). Then Person may
> be a entity bean with Adress attribute(s) or references. Using RDBMS you
> can
> persist this Java class in one blob (which seems to be to usual solution
> with CMP though Some CMP solutions may provide some custom mappers) or you
> can use BMP and write the required code to persist the class in
> appropriate
> table/columns. Blobs makes it difficult to figure out what's stored in
> your
> database if you are using some query tools.
> 2. Use the entity beans for Address too. For many cases this seems a
> pretty
> heavy-weight solution.
>
> You also have to decide what to do when the Person instance is deleted.
> Usually you want to delete the dependent objects too.
>
> Regards,
> Jouni
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Monson-Haefel
> > Sent: Tuesday, February 22, 2000 11:16 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Dependent classes
> >
> >
> > That last post was difficult to read, so here it is again with
> > the line breaks
> > fixed:
> >
> > "Dependent objects are objects that only have meaning within the
> > context of
> > another business object. They typically represent fairly
> > fine-grained business
> > con-cepts, like an address, phone number, or order item. For example, an
> > address has little meaning when it is not associated with a
> > business object
> > like Person or Organization. It depends on the context of the
> > business object
> > to give it mean-ing. Such an object can be thought of as a
> > wrapper for related
> > data. The fields that make up an address (street, city, state,
> > and zip) should
> > be packaged together in a single object called Address. In turn,
> > the Address
> > object is usually an attribute or property of another business
> > object; in EJB,
> > we would typically see an Address or some other dependent object
> > as a property
> > of an entity bean."
> >
> > -- Richard
> > --
> > Author of Enterprise JavaBeans
> > Published by O'Reilly & Associates
> >
> > EJB FAQ
> > http://www.jguru.com/faq/EJB
> >
> > EJBNow.com
> > http://www.ejbnow.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".
>
> ==========================================================================
> =
> 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".
