not Vlada but what the heck... i'm (more-or-less) awake right now ;)
here are a few definitions that come to mind:
D1. when an entity is defined more by its relationships than by its parent,
it deserves to be a full-blown entity.
D2. when it is possible to view an entity in isolation and derive meaningful
context (as opposed to simple data), it deserves to be a full-blown entity.
D3. when an entity has a single natural parent, it's probably a
dependent-object. order item has a strong parent in order. order has no
single parent but rather a number of relationships that can be regarded as
parents.
regarding business processes that may want to deal with order items, a good
solution is to use a java class. i'll restrain myself and simply state that
a session bean isn't required for access to this data (i know, shut up jim
and get to the point). you also need no SQL in particular to deal with the
items (the items are not defined by SQL at all). if the items are
implemented as a java class, simply persist it as an attribute of the order
object. the java class that represents the order items should contain
metadata and methods that allow friendly java access to it. it should also
be extensible to allow structure modifications (just as you periodically
need to add attributes to tables in a relational database).
regarding penalties: one item to consider is that you'll very much benefit
from having java in your pstore. this allows seamless access to your java
classes from within the pstore itself. if you're using a java-enabled
relational database (db2, oracle), you get alot of object database
capabilities by doing this. note that with this structure, you actually cut
down on the number of entity beans in your system - and they'll all be
first-class entities.
> -----Original Message-----
> From: Lennart Petersson [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, June 17, 1999 11:47 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Using collection bean to represent a list of entity
> beans- was RE : Application Server container related question
>
> Hi Vlada!
> When you say "dependent objects" (sub-entities), what are your definition
> of it? When does a potential
> Entity Bean change to only be a dependent object - not worth it's own
> Entity Bean? In my experience of
> developing administrative systems we have a lot of "dependent objects",
> you may even say that nearly all
> of them are "dependent objects" owned by some other data. When we now are
> rethinking (again, that's life
> :-) about our handling of head_and_rows data (like an order with it's
> order items) we definitly holds
> Entity Beans as a solution to handle the rows (order items). The order
> items is a dependent object that
> would not exists without it's parent, the Order, but other business
> processes may have interest of the
> order items without grouping them togetther as an Order (statistics is one
> example). If the order item
> should be implemented as a Java class then we always would have a wrapper
> (session bean) when some one
> other than Order would like to interact with them. This wrapper would have
> to have the order items SQL
> statements hardcoded and the more wrapper we have...
>
> What are the penalty that i would pay for this? Ok, there may be a lot of
> entity beans hanging around in
> the server. Performance?
>
> /Lennart
>
> Vlada Matena wrote:
>
> > I agree with what Ian says in this and his previous emails on
> sub-entities. We call sub-entities
> > "dependent objects". As there is no EJB API for dependent objects (the
> container is
> > not aware of them), we hardly mention them in the spec. In the section
> on entity beans, we
> > have a short discussion on how to identify a dependent object in an
> application design.
> > We recommend implementing dependent objects *not* as Entity beans, but
> as Java classes.
> > >From the perspective of the container runtime, the Java classes appear
> as part of the "parent"
> > Entity bean to which they are logically linked.
> >
> > It would be nice to be able to defer the decision whether a component is
> an Entity bean or a
> > dependent
> > component (i.e. sub-entity) to deployment time, not to be forced to
> hard-code this decision at
> > the component development time. Although the EJB spec currently does not
> architect this, I think
> > that a component developer can create components that can be deployed
> both as dependent
> > objects and as fully-blown Entities.
> >
> > Vlada
> >
>
> --
> ________________________________
> Lennart Petersson
> Benefit Partner AB
> Bergendorffsgatan 5A
> S-652 24 Karlstad
> Phone: +46 (0)54 186800
> mailto:[EMAIL PROTECTED]
> http://www.benefit.se
>
> ==========================================================================
> =
> 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".
