rows by merging all database rows where selected fields in two different
tables match. Database engines are highly optimized and process joins many
times faster than we can. One common place that entity bean solutions can
encounter application joins is with reporting. Because reports often present
renormalized (joined) data, container-managed entity beans can lead to
implementations that perform poorly.
One-to-many joins occur frequently with object models. For example,
when we build the invoice in figure 8.4, container-managed persistence would
be forced to process several joins in our application.
Reporting can often be best handled outside the realm of EJB s, perhaps
with a view. Too many entity beans can lead to application joins and to the next
problem. One particularly common problem is the creation of relationship
EJB s. DBA s create relationship tables in a database environment, but in the EJB
domain, relationship objects can lead to too many joins and poor performance.
Solution: Views, mappers, bean-managed joins
One painful solution to entity bean joins is to measure performance and make
improvements where significant problems surface. We can use bean-managed
joins in those problem areas and then code the database joins manually. This
solution tends to break the portability of a solution between databases, but
good attention to open SQL programming can alleviate this concern.
A more elegant alternative is to provide a view and use a facade instead of
an entity bean. Or you can use object relational mapping software, such as
WebGain's TopLink. These solutions allow objects with complex relationships
to be saved and restored efficiently.
Mini-antipattern: Entity Beans for Lightweight Functions
If a method simply returns a list, there may be times we should go right to the
database rather than use a full-blown EJB model. For our BBS , the list of
boards is a perfect example. Extending our model to load full boards when all
we need is a list of board names is extremely heavy-handed.
Instead, we can simply add a JDBC interface to our facade. It's an easy
extension to make. This method signature is added to the remote interface,
which is added to BoardFacade.java :
java.util.List getBoardNames() throws java.rmi.RemoteException;
Listing 8.5 contains the implementation, which is added to BoardFacade-