Developing with POJOs: faster and easier - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 19

Another approach, which is described in detail in chapter 7, is for the business
tier to return detached objects. A detached object is a previously persistent object
that is no longer connected to the database. Instead of copying values from a per-
sistent object into a DTO , the business tier detaches the object and returns it to
the persistent tier. This approach eliminates the need for DTO s while keeping all
database accesses in the business tier.
Different persistence frameworks handle detached objects in different ways. In
Hibernate and EJB 3 , objects are automatically detached but the application must
ensure that all of the objects required by the presentation tier are loaded, which
can sometimes require extra calls to the persistence framework. In JDO 2.0 an
application must explicitly detach the required objects by calling a JDO API .

Using a façade to retrieve and detach domain objects
An important design decision is determining which class will be responsible for
calling the persistence framework to retrieve and detach the objects required by
the presentation tier. For example, the money transfer business logic must
retrieve the recent transactions and detach them along with the account objects.
You could make this the responsibility of the TransferService , but doing so would
make it more complicated and couple it to the needs of the presentation tier.
Moreover, because the business tier must sometimes call the persistent framework
to ensure that the domain objects can be returned to the presentation tier, mak-
ing the TransferService call the detachment logic would mix together pure busi-
ness logic with infrastructure details.
Unless the service is very simple and contains little or no business logic, a bet-
ter option is to retrieve and detach the required objects in a separate class—
TransferFacadeImpl . As figure 1.4 shows, TransferFacadeImpl implements the
TransferFacade interface, which specifies the methods that can be called by the
business logic's client and plays a role similar to that of an EJB component inter-
face. It returns a TransferResult that contains the domain objects.
Like the EJB we saw earlier, TransferFacade defines a transfer() method that
returns a TransferResult . It calls TransferService and TransactionRepository ,
and creates TransferResult . As you can see, TransferResult is the only DTO in
this example. The rest of the objects returned to the presentation tier are domain
objects. Later in chapter 7, we look at a more elaborate example of a façade.

1.2.5 Making POJOs transactional

Let's review what we have done so far. We replaced a procedural design with an
object-oriented design, replaced entity beans with POJO s plus a persistence frame-
work (either Hibernate or JDO ), and eliminated DTO s. Because of these changes,