Java Reference
In-Depth Information
When my son was younger, he liked to play with a toy that involved matching
shapes with the corresponding holes. At first, he struggled to put the right shape
in the right hole. It took him a while to realize that it's impossible put a round peg
into a square hole. But eventually, he developed good shape recognition and
matching skills and was able to master the game.
When developing enterprise Java applications, we have to do the equivalent of
putting a round peg into a square hole. Because object databases never became a
mainstream technology, we must store objects in a relational database. When pro-
cessing a request, an application has to move domain objects between the JVM
and the database. It must load an object from the database before invoking any of
its methods or accessing any of its fields, and it must save the object back to the
database if it has been modified. Persisting objects is a remarkably challenging
problem because of the significant differences between a domain model and a
database schema—the so-called impedance mismatch.
Persisting a domain model is made even more difficult by the need to do it
without the classes knowing that they are persistent. The term for this is transpar-
ent persistence , and it's important because it simplifies development considerably. It
enables classes to be POJO s and decouples them from the database. In contrast,
EJB 2.0 entity beans are an example of nontransparent persistence and you know
about their problems. However, as you will learn in this chapter, implementing
transparent persistence is difficult because objects and databases are accessed in
very different ways.
In this chapter you will learn why using an ORM framework is much better
than trying to solve these problems yourself. I explain how to map the classes and
relationships of an object model to a database schema. I describe the key features
of ORM frameworks and provide an overview of JDO and Hibernate, which are two
popular options. You will learn how to effectively test a persistent domain model
and see some repository design techniques that make testing easier.
4.1 Mapping an object model to a database
If you have developed a domain model such as the one shown in figure 4.1, then
you must map its classes and their fields to tables and columns in the database.
But how do you map a network of interconnected objects to a database
schema, which has a flat structure consisting of tables and columns? Important
OO concepts such as inheritance have no corresponding database equivalent.
The rich set of relationships between objects doesn't map easily into the foreign
key relationships between tables. Object identity and lifecycle also don't translate
 
 
 
Search WWH ::




Custom Search