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".
