Robert,
There are some suggestions on this particular design issue in the archives.
I think you should have Order as a Bean, and OrderEntry (I assume these
areline items) as non-bean sub-objects.
-Chris.
> -----Original Message-----
> From: Robert Krueger [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, August 26, 1999 5:35 PM
> To: [EMAIL PROTECTED]
> Subject: design question with entity beans
>
> Hi,
>
> suppose I have to model an entity (say Order), that aggregates a vector
> of other entities (say instances of OrderEntry) and I would like to
> avoid the performance problem of reloading/storing all the aggregated
> entities (because there possibly is a large number of them) on each
> access to methods of entity bean class Order. would it be ok to put
> methods that access the db directly (like addOrderEntry,
> getOrderEntries) into the entity bean Order and not model OrderEntry as
> an entity bean? does this violate the spec or is it bad design and there
> are much better patterns for modeling the problem without performance
> problems? are there data integrity problems with this approach?
>
> thanks for your help,
>
> robert
>
>
> --
> (-) Robert Kr�ger
> (-) SIGNAL 7 Gesellschaft f�r Informationstechnologie mbH
> (-) Br�der-Knau�-Str. 79 - 64285 Darmstadt,
> (-) Tel: 06151 665401, Fax: 06151 665373
> (-) [EMAIL PROTECTED], www.signal7.de
>
> ==========================================================================
> =
> 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".
