Overview of persisting a domain model - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 109

4.2.1 Why you don't want to persist objects yourself

There are three main challenges when trying to persist objects. One is enabling
the application to navigate relationships between domain objects while minimiz-
ing the number of objects loaded from the database. When an object is loaded,
the database access code does not know which related objects will be later
accessed by the application. Loading all of the objects that might be accessed is
extremely inefficient because an object graph (which is the set of objects that are
accessible from the root object) can be quite large. The database access code must
instead implement a mechanism called lazy loading that loads objects on
demand, when they are first accessed.
The second major challenge is writing back to the database only those objects
that have been modified. An application might load a large number of objects and
yet only modify a few of them. It would be extremely inefficient to save all objects
regardless of whether they have changed. It would also be unreasonable and error-
prone for the application to remember the modified objects. The database access
code must keep track of which objects need to written back to the database.
Also, as I mentioned earlier, the database access code must preserve object
identity by ensuring that there is a single in-memory instance of a persistent
object when processing a request. It must keep track of every object that is loaded
by maintain a map between primary keys and objects—the so-called Identity Map
pattern [Fowler 2002]. The database access code must look in the map before
loading an object from the database. This is certainly not difficult to do, but it
adds additional complexity to the database access code.
As you can envisage, database access code that implements features such as lazy
loading and change tracking can become extremely complex. Most applications
must use an ORM framework, which handles these and a myriad of other issues.

4.2.2 The key features of an ORM framework

An ORM framework solves the difficult problem of storing objects in a relational
database. You tell the framework how your domain model maps to the database
schema, and it takes care of getting your objects in and out of the database. This
enables you to focus on solving your business problems rather than writing lots of
low-level database access code.
The key features of an ORM framework are as follows: