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.