Taking the example of order items, I am still not convinced why they should
be only first class entities but not first class entity beans. Why shouldn't
dependent objects be full blown entity beans ? Are we trying to avoid too
many entity beans and as a result compromising object design ? I'm going
with the assumption that the order items are important business entities and
need to exist independently and not just as a blob attribute on an order.
Persisting whole entities as an attribute makes me unconfortable (atleast
today).
Reasons I see for an order item being an entity bean.
1. I feel they have behavior , business logic and *business data attributes*
asociated with them which need to persisted independently.
2. I feel a lot of the value that EJB brings is in container managed
persistence so that bean developers can be more productive writing business
logic and not have to worry about persisting classes. If we want to use CMP
(and the assumption here is that the order item should not be just a blob
attribute of the order) then making the order item an entity bean seems to
make sense.
3. The system could grow and other objects could have relationship with
order items directly intead of always having to go through the order bean.
4. I don't like the idea of the order entity bean having the responsibility
of persisting all the attributes of an order and persisting all the order
items and the attributes of each order item.
What do you think about these reasons ? I would like some more insight on
why order items should not be entity beans.
Sachin.
> 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".
>
>
===========================================================================
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".
