> 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.
[Chip Wilson]
Ahhh yes, you are correct, but that does not imply that they must be entity
beans.
> Persisting whole entities as an attribute makes me unconfortable (atleast
> today).
[Chip Wilson]
They should not be persisted as an attribute. You are equating database
rows with entity beans. They are very different things.
> 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.
[Chip Wilson]
They do. That does not imply that they should be an entity bean, only that
they should have a separate domain class and a separate database table.
> 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.
[Chip Wilson]
CMP can be very useful, but only if it is well implemented. Mapping domain
objects to a relational database is a complex task. Class == table is the
most simplistic mapping, and almost never works for a reasonably complex
domain. If the CMP you're using only supports class == table, and further
imposes entity == class == table, then it is not useful at all in my
opinion.
> 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.
[Chip Wilson]
Then they are not dependant objects. You should model your domain
completely during analysis and determine whether this will ever occur. This
decision will impact your dB schema as well as your domain and component
models.
> 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.
[Chip Wilson]
The entity should be responsible for the section of the domain graph for
which it is serving as a facade. As far as persisting that graph is
concerned, this is the responsibility of the persistence layer. Entity
Beans are a part of the domain layer.
Your OrderEntity Bean in this case is a facade to a single Order domain
object, which aggregates many OrderItem domain objects. You probably have
an ORDER table and an ORDER_ITEM table which has a foreign key back to the
ORDER table. One entity, two domain classes, two dB tables. I am sure that
it is more complicated than this, but the example serves the purpose.
> 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".
>
===========================================================================
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".
