The idea that entity beans should only be used for updates is misguided.
Entity beans (enterprise beans) represent data and behavior. The behavior part is
important to this discussion because it justifies the use of both accessor and
mutator (update) methods in the bean's remote interface. Limiting entity beans to
only mutator methods reduces them to data objects, not business components. As a
business component, an entity bean represents the full spectrum of behaviors
associated with a persistent business concept. An entity bean that represents a
Patient, for example, provides methods for reading the patient's benefit data while
processing a claim; reading a patient's medical history for counter indications;
determining a patient's preferred care provider for scheduling appointments, etc.
If you remove the behavior for accessing data from an entity, you loose the ability
to manage a patient individually. EJB allows thousands of client applications to
concurrently manage entity business objects individually. This is what makes entity
beans so powerful. Without it, you're better off using something like JDBC
directly.
There are many situations where the use of enterprise beans is inappropriate. If
your system presents lists and tables of data representing many entities for read
only access, then you should consider using a mechanism other than EJB. For
example, a commercial web site that is used for shopping, like Amazon.com or
eToys.com, would not use EJB to populate web pages with product information in
response to customer navigation and searches. A better approach in this situation
is to access the data more directly from Servlets using JDBC (proper connection
management is assumed). When, however, the client is processing a purchase, which
is a task applied to an individual purchase order, EJB should be used. (EJB might be
accessed indirectly by clients through Servlets.) In this scenario a stateful
session bean might be used to represent the client's shopping cart, while entity
beans represent the client, the chosen products, and the order itself.
A hospital system, on the other hand, would use EJB every time a Patient record was
accessed so that the behavior (both declarative and business logic) could be applied
in the context of an individual's data. This is important when reading/updating data
specific to an individual. If, however, you needed to generate reports on all the
patients you would not use EJB. Instead of EJB, use a reporting product; something
that is designed to search, filter, and organize data for reporting. In the medical
system, EJB ensures that very large user populations can concurrently manage
thousands of individual patients safely and appropriately -- it's not a reporting
tool.
EJB is not a silver bullet; it's only one part of a complete solution. The use of
both JDBC and EJB from Servlets, as illustrated in the shopping cart scenario, is an
example of how to properly use EJB in the context of a larger solution. EJB is a
powerful new weapon in our enterprise arsenal. Use it properly, within the right
context, and it will serve you well.
If you find yourself making component design decisions that are counter to the EJB
programming model -- like using entity beans for updates only -- then you should
reevaluate your entire architecture because you are probably using EJB
inappropriately.
Thanks,
Richard
--
Author of Enterprise JavaBeans
Published by O'Reilly & Associates
EJB FAQ
http://www.jguru.com/faq/EJB
EJBNow.com
http://www.ejbnow.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".
