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

returns true if the two operands reference the same object. In the database, the
identity of a row is its primary key, which is a column or set of columns that
uniquely identifies a row in table. Two objects in a relational database are the
same if they map to the same row in the same table.
The differences between Java identity and database identity impact the appli-
cation in a number of ways. Usually, an application must assign a primary key to a
persistent object. The primary key can sometimes be a natural key, which is a
value that has a business meaning, such as a social security number. However,
because even a social security number can change, it is almost always better to use
a surrogate key, which is a unique value generated by the application or database.
The application typically stores the primary key in the object for easy access. This,
of course, requires each persistent class to define a field to store it.
Also, when processing a request the application must ensure there is only a sin-
gle in-memory instance of a persistent object in order to guarantee that the data-
base identity matches the Java identity. Otherwise, if there were two copies of the
same persistent object in memory the application would behave incorrectly. Cor-
rectly managing the identity of persistent objects is tricky, and as you will see in
the next section, one of the main benefits of using an ORM framework is that it is
handled automatically.
4.2 Overview of ORM frameworks
Now that you seen the different ways of mapping a domain model to a database
schema, let's tackle the problem of getting objects in and out of the database.
Each request handled by the application results in one or more calls to the busi-
ness tier, which accesses, instantiates, updates, and deletes domain objects.
Because these objects are persistent, the application must execute SELECT state-
ments to load them from the database and execute INSERT , UPDATE , and DELETE
statements to update the database to reflect the changes made to them.
If the domain model is extremely simple and used in a very straightforward
way, you might be able to persist it yourself using JDBC or iBATIS . For example,
writing the code to load and save an individual domain object using either of
these technologies is not difficult. But imagine how much database access code
you would have to write to persist a large domain model. It could be overwhelm-
ing. It would be like trying to demolish an iceberg with an ice pick. In addition,
the database access code has to solve some challenging problems. Let's examine
those challenges and see why you don't want to solve them yourself.