Java Reference
In-Depth Information
needed two classes to represent an entity: one that was always connected, and one that was
never connected. The former was called something analogous to
ProductEJB
, and the
the
ProductEJB
held the data for a single row, and its data was transferred to a
Pro-
ductTO
for display. The transfer object wasn't connected, so it could get stale, but at least
it didn't use up a database connection, which is a scarce commodity. Transferring the data
from the EJB to the TO was done by a session EJB, where the transaction boundaries oc-
curred. The session EJBs formed the service layer, which also held business logic. The
whole process was much like that shown in
figure 8.2
.
6
Older terms included Data Transfer Object (DTO) and Value Object (VO).
Figure 8.2. Controllers contact transactional session EJBs, which acquire database data through entity EJBs. The
data is copied to transfer objects and returned to the controller.
The result is that the
ProductEJB
class and the
ProductTO
class were essentially
identical, in that they both contained the same method signatures, even though the imple-
mentations were different. Martin Fowler (author of
Patterns of Enterprise Application Ar-
chitecture
[Addison-Wesley, 2002],
Refactoring
[Addision-Wesley, 1999], and several oth-
er books) calls that an anti-pattern and says that it's a symptom of a flawed design.
One of the key differences between Hibernate and EJBs is the concept of a Hibernate ses-
sion. The innovation was that, rather than one class of objects that were always connected
and another class of objects that were never connected, what was needed was a set of ob-
jects that were sometimes connected and sometimes not. In Hibernate, when objects are
part of a Hibernate session, the framework promises to keep them in sync with the data-
