>As you said , using the entity bean would certainly be overhead for read
>only data ...
>Would it be good to use session bean (with JDBC code for SELECT query)
>instead. What say ?
I completely disagree. For read only data, if you have an application
server that supports entity bean caching (and every notable app. server
does) or the notion of read-only beans, then it is much faster to use entity
beans for read only data.
Consider an online car dealership. The stats of cars rarely change, so they
could be modeled as read only car entity beans. Now if a user browses
through the inventory of cars, it will be much, much faster to grab this
data from an in memory entity bean than it would to open a connection to a
database and query for the same data every time someone browses the
catalogue.
Asides from a mechanism for persistence, the other main value add of entity
beans is caching. This makes entity beans a better choice over JDBC from
session beans for many cases.
Floyd Marinescu
---------------------------------
Senior Architect / Director of Marketing
The Middleware Company
http://www.middleware-company.com
http://www.TheServerSide.com
[EMAIL PROTECTED]
416-889-6115
Check out TheServerSide.com, the internets first J2EE community!!!
===========================================================================
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".
