Programming Jakarta Struts, 2nd Edition [Electronic resources] نسخه متنی

6.3 Persistence

In general,
persistence
means that the data that is input into an application, either by a
human user or by other means, will exist beyond the lifetime of the
application. Even though the application may exit or the computer may
shut down, the information will survive. This obviously is very
important to an organization. Every small, medium, and large
organization has the need to persist data.

6.3.1 Persisting Business Objects

When objects
are created in memory for an application, they can't
stay there forever. Eventually, they must either be cleaned up or
persisted to a data store. Memory is volatile, and an application
might crash or need to be stopped for maintenance. Without
data
persistence, there's no record to indicate what was
ordered, for example, or whom to charge.

Business objects represent information that must be kept. To be of
value, orders, items, and customer information must be persisted for
an application like the Storefront. Losing a
customer's order is not going to make the customer a
customer for long. Once the data has been persisted, it can be
retrieved and used to reconstruct the business objects at a later
time.

6.3.2 Storing Objects into a Relational Model

Although there are many
different types of data stores, relational databases are used quite
frequently to store the data for an organization, especially with
applications like the Storefront. Relational databases are a
necessity, and their use is widespread. There are, however, several
obstacles that must be overcome to use them successfully. One of the
biggest challenges is solving the so-called
"impedance mismatch."

6.3.2.1 The impedance mismatch

Objects hold state and behavior and can be traversed through their
relationships with other objects. The relational paradigm, on the
other hand, is based on storing data and joining sets of data by
matching overlapping fields. Essentially, a relational database is a
very "flat" view of the data. This
difference leads to a challenging mismatch between the two worlds:
objects must be flattened before they can be stored into a relational
database, but the relationships that objects have to one another also
must be persisted in order for the object hierarchy to be reassembled
correctly.

Object databases don't require the data to be flattened out. However, they are not yet as widespread as relational databases.

There's not enough room in this chapter for a
detailed tutorial on mapping objects to a relational model. Suffice
it to say that there are many challenges. Fortunately, many resources
and references are available to help in overcoming these challenges.
A definitive source of information on how to correctly map objects to
a relational database can be found in Scott Ambler's
white paper, "Mapping Objects to Relational
Databases" (see http://www.ambysoft.com/mappingObjects.pdf).

As you'll see shortly, there are many
object-to-relational mapping (ORM)
frameworks that make this job much easier for the Java developer.
Such frameworks don't completely eliminate your need
for a good understanding of the problems, but they can hide many of
the ugly chores that no developer wants to perform.