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
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of John Harby
Sent: 03 January 2001 23:17
To: [EMAIL PROTECTED]
Subject: Re: Coarse grained and Fine grained beans
With respect to the case of component granularity, the
blueprint states that the entity bean should correspond
to a "logical row". Granted, in DB modeling jargon, a
logical row may represent an aggregation of physical rows.
I have found in practice that using a denormalized layer
within the DB schema so that coarse entity beans still correspond
to only one denormalized table can be optimal in large apps.
I will admit that I have only used this strategy in cases where
the DB vendor had alot of support for replication and resolution
of the denormalized layer back into the actual E-R schema.
>From: Thibault Cuvillier <[EMAIL PROTECTED]>
>Reply-To: Thibault Cuvillier <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Coarse grained and Fine grained beans
>Date: Wed, 3 Jan 2001 13:45:03 -0600
>
>Samuel,
>
>There is 2 granularity problem when you design Entity EJBs:
> - Component granularity
> - Accessors granularity
>
>
>1-- Component granularity
>---------------------------------
>There is two extrem solutions when you create EJbs
>
>1- Create small, fine grained EJBs.
> - Usually, you create 1 EJB per table
> - i.e.: PersoneEJB and AddressEJB
>
>2- Create BIG, coarse grained EJBs.
> - Represent an aggregat of data stored in different tables
> - i.e.: PersoneEJB with a method getAddress
>
>When you design an EJB entity, you must keep in mind that you are designing
>a remote object interface, not only a way to access the data without
>writing
>JDBC code.
>
>An EJB should not be too small, or too BIG. Easy to say...... so, here is a
>few clue:
>
>Syndroms if you design too small EJBs:
> - Performace will be low because you will need to many remote calls
> - System supervision may be challenging
> - Communication between EJBs will be unmanageable
> - A lot of small SQL queries to the database
> - You will need to write more code to implement your system
>
>Syndroms if your design too BIG EJBs:
> - ejbLoad and ejbStore will take too long time
> - The component use too much memory
> - System modularity will be low as well as it capability to evolve.
>
>When you create EJB, you must always respect the rule described in the EJB
>spec:
>"A dependent object should never been modelized as an EJB". (see the spec
>for more detailed)
>
>
>2- Methods granularity
>-------------------------------
>Accessors ( get and set methods ) also have a granularity:
>
>Fine grained:
>
> EJB Person:
> getFirstName
> getLastName
> getZipCode
> ...
>
>Coarse Grained:
> EJB Person:
> PersonStateHolder getStateHolder
>
> The state holder ius a serializable object containing a copy of the
>attributes.
>
> class PersonStateHolder implements Serializable {
> String firstName;
> String lastName;
> String zipCode;
> ...
> }
>
>Usually, an Entity EJBs contain fine grained and coarse grained methods.
>
>
>3-- So...
>There is 2 common errors when designing Entity EJBs:
> - Create one Entity per Table
> - Create one Entity per conceptual class
>
>Entity EJB design must:
> - Optimize the data load/store
> - Optimize the remote calls
> - Optimize the memory/CPU usage on the server
> - Allow an easy deployement and system management
> - Allow re-use, if it's required on the project
> ...
>
>Finding the right component granularity require experience: there is no
>magic-generic rules. You have to understand what's happen if you define too
>small grained or too large grained components.
>
>Hope this help
>
>Thibault Cuvillier
>http://www.valtech.com
>
>===========================================================================
>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".
>
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
===========================================================================
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".
