Johan,
EJB entities is a common solution to 2 different problems:
- Distribution (maintain a shared state on the server)
- O/R mapping
>From the O/R mapping point of view,
"An entity bean represents an object view of business data stored in
persistent storage or an existing application."
... is a correct definition.
But because entities are distributed:
"An entity bean is better suited to represent a coarse-grained business
object that provides more complex behaviour than only get and set methods
for its fields."
... is a better one.
The EJB spec does not dissociate the 2 problems:
- Access remotly a shared state on the server, which require coarse
grained interfaces
- Persistence layer (such as JDO) to access the O/R mapping level, which
usualy has interfaces close to the conceptual model (fine grained).
The EJB interfaces give a de-normalized view (coarse grained) on the
persistence layer.
The persistence layer give a normalized view (fine grained) of the DB
schema, close to the conceptual model.
The DB scema is more or less normalized, but the normalization level is
hidden by the persistence layer.
Entity EJB is a "Janus", double face concept.
My 2 cents,
Tibo.
>-----Original Message-----
>From: Johan Eltes [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, January 03, 2001 6:52 PM
>To: [EMAIL PROTECTED]
>Subject: Re: Coarse grained and Fine grained beans
>
>
>In my oppinion, the BluePrint actually defines two incompatible
>use-models,
>just a few sections apart - one in the perspective of entity
>beans as an
>ORDB framework and one in the perspective of EJB Entity Beans as
>distributed
>objects:
>
>[Sun J2EE Blueprint, section 5.2] "An entity bean represents an object
>view
>of business data stored in persistent storage or an existing
>application.
>The bean provides an object wrapper around the data to
>simplify the task
>of
>accessing and manipulating it."
>
>[Sun J2EE Blueprint, section 5.3.1] "...Therefore modelling
>every object
>representing a row in the database as an entity bean is not
>recommended.
>An
>entity bean is better suited to represent a coarse-grained business
>object
>that provides more complex behaviour than only get and set methods for
>its
>fields."
>
>So even Sun has a hard time finding a use-model for EJB Entity
>Beans :-)
>
>/Johan
[cut]
===========================================================================
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".
