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

Object caching
Earlier I described how an ORM framework must maintain a map of primary keys
and objects to ensure that only one copy of an object is loaded. The map acts also
as a cache and improves performance by eliminating database accesses. When
loading an object, the persistence framework can check the cache before access-
ing the database. By default, an ORM framework caches objects for either the
duration of a request or the duration of a transaction. It can also be configured to
cache objects for longer, which can sometimes improve performance consider-
ably. For example, the application can keep read-only objects in a process-level
cache and so rarely have to go to the database. An application can also cache data
that is updated, but this can be tricky if the application is running on a cluster or
the database is updated by another application.

Detached objects
One of the most tedious parts of developing a classic J2EE application is writing the
DTO s, which contain a copy of the data stored in the entity beans that implement
the domain objects and are returned to the presentation tier. Fortunately, we no
longer need to copy data into DTO s because one of the exciting features of modern
ORM frameworks is what are called detached objects.
A detached object is one that is no longer persistent but that contains data from
the database and keeps track of its persistent identity. The business tier (usually
the POJO façade) can return a detached object to its client instead of creating a
DTO , which means that you need to write a lot less code.
What's more, detached objects make it easier to write edit-style use cases,
which are use cases that allow the user to edit data from the database. The presen-
tation tier can update one or more detached objects to reflect a user's changes.
Then when the user saves the changes, the presentation tier passes the modified
detached objects back to the business tier. The business tier (usually the POJO
façade) reattaches them by calling the ORM framework, which updates the data-
base. See chapter 13 for an example of such a use case.

4.2.3 Benefits and drawbacks of using an ORM framework

Using an ORM framework has several benefits and drawbacks. Let's look at each one.

Improved productivity
One important benefit of using an ORM framework is improved productivity. You
have significantly less code to write. The framework takes care of generating and
executing the SQL statements, which means you can focus on developing the