Encapsulating the business logic with a POJO façade - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 245

client, the presentation tier. The EJB way of encapsulating the business logic is to
use a session façade, and the POJO approach is to use a POJO façade. We saw in
chapter 1 that the concept of a POJO façade is very straightforward. Rather than
encapsulating your business logic with heavyweight session beans, you simply use a
POJO in conjunction with a lightweight container such as the Spring framework.
Like an EJB session façade, a POJO façade exposes a coarse-grained interface to
the presentation tier. It handles requests from the presentation tier by delegating
to the business logic.
One key difference between a POJO façade and an EJB session façade is that
instead of using services provided by the EJB container, the POJO façade uses an
AOP framework such as Spring AOP to manage transactions and persistence frame-
work connections. The AOP interceptors automatically begin and commit transac-
tions and open and close persistence framework connections. The POJO façade's
client—i.e., the presentation tier—simply gets the façade from the lightweight con-
tainer, which instantiates the façade and applies the necessary interceptors.
Another key difference is that the POJO façade returns domain objects instead
of DTO s to the presentation tier. For example, as you will see a bit later, the POJO
façade that implements the Place Order use case returns the PendingOrder
domain object instead of a DTO containing a copy of its data. This simplifies the
façade considerably because you do not have to define a DTO for each domain
object and write the code to construct it, which in some applications is as much as
10 percent of the code.
In this section you will learn about the benefits and drawbacks of using a POJO
façade and when to use one. But let's first look at an example.

7.1.1 An example POJO façade

To see how a POJO façade works, let's look at the PlaceOrderFacade . The Place-
OrderFacade handles requests from the presentation tier components that imple-
ment the Place Order use case and invokes the domain model that was developed
earlier in chapter 3. For example, one of its methods is updateDeliveryInfo() ,
which is invoked by the presentation tier when the user enters the delivery address
and time. This method calls the PlaceOrderService to create or update the Pend-
ingOrder . The PlaceOrderFacade also invokes the RestaurantRepository to get the
available restaurants. The PlaceOrderFacade returns the detached PendingOrder
and Restaurant objects to the presentation tier, which displays them to the user.
Figure 7.1 shows the structure of the PlaceOrderFacade and its relationship with the
presentation tier and the domain model.