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