Java Reference
In-Depth Information
Data Access Object
Problem
The eInsure application relied heavily on entity beans for database operations. Way back
in 1999, when entity beans first made their appearance (as part of the EJB 1.
x
specifica-
tion), they were thought to be a remarkable enterprise component that would completely
change enterprise software development, deployment, maintenance, and portability.
This thinking was backed by reason. Entity beans provided standard-based, container-
managed, distributed, secure, transactional persistence components. They provided
transparent and automatic persistence without the client worrying about the underlying
data store. But this popularity was only short-lived. As developers, designers, and archi-
tects started using entity beans, the problems became apparent. They soon realized that
most of the features offered by entity beans, except persistence, were not required in
their applications. The distributed nature of entity beans led to fine-grained calls from
the clients. This increased network traffic and had an adverse impact on performance.
The Session Facade pattern described in Chapter 4 was a solution to tackle this fine-
grained entity bean access. The session bean also took care of security and transactional
requirements.
With the quickly declining usage, the EJB 2.
x
specification introduced the concept of
local interfaces to at least alleviate the problems of network trips. But this still did not
address the complexity involved in developing entity beans. Entity bean development
required four Java source files comprising the home and remote interfaces, the bean
implementation, and a primary key class. Apart from the Java sources, you had two to
three deployment descriptors depending on your server vendors. You are already aware
of the two deployment descriptors from session beans in Chapter 4. Some application
servers used a third deployment descriptor for mapping the database table and column
to the bean class and its properties. Because the entity beans ran inside the EJB contain-
ers, they were difficult to test. The result was long development cycles and maintenance
overhead.
The developers' problems were compounded by the side effects of using entity
beans. Because the accessing of getter/setters in entity beans were remote method invo-
cations, the data transfer objects (DTOs) were designed to extract all the data from the
entity beans in just a single method call. The DTOs were simple POJOs with getters and
setters and implemented the
Serializable
interface. In a large to midsize project that had
several DTOs, these classes added to the maintenance problem. A small field change in
any DTO often resulted in compilation failures in multiple source files.
The development community had no choice but to move to lightweight persistence
solutions provided by ORM frameworks such as Hibernate, Kodo, iBatis, and others.
These products focused on the persistence of POJOs with minimal configuration infor-
mation. This proved to be a telling blow for entity beans, and it finally made way for JPA
