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

private PlaceOrderService service;
public PlaceOrderFacadeImpl(
bb PlaceOrderService service,
bbbbbb PlaceOrderFacadeResultFactory resultFactory) {
this.service = service;
this.resultFactory = resultFactory;
}
public PlaceOrderFacadeResult updateRestaurant(
String pendingOrderId, String restaurantId) {
PlaceOrderServiceResult result = service.updateRestaurant(
pendingOrderId, restaurantId);
return resultFactory.make(PlaceOrderStatusCodes.OK, result
.getPendingOrder());
}
…
}
The updateRestaurant() method first calls PlaceOrderService.updateRestau-
rant() . It then calls the PlaceOrderFacadeResultFactory to create a return value
containing a SUCCESS status code and the PendingOrder . The other PlaceOrder-
Facade methods are similar to updateRestaurant() . Each one calls the correspond-
ing PlaceOrderService method. Some of these methods also call repositories to
retrieve additional data needed by the presentation tier. For example, update-
DeliveryInfo() calls RestaurantRepository to find the available restaurants.
PlaceOrderFacadeImpl is a pretty simple class, and so you might be wondering,
why not simplify the design and implement its functionality as part of the Place-
OrderService ? One good reason to have a POJO façade is that it enables the
domain model services to focus on the core business logic. They can be developed
independently of the presentation tier because they are not responsible for gath-
ering data for the presentation tier of the domain model services. Another benefit
of using a POJO façade is that it enables the same domain model services to work
with multiple presentation tiers and other kinds of business-tier clients. While
merging the POJO façade and the domain services might make sense for some
applications, many applications will benefit from keeping them separate.
As well as invoking the domain model services and repositories, a POJO façade
must detach the domain objects that it returns to the presentation tier. To ensure
that the POJO façade is easy to test, the detachment code, which must sometimes
call the persistence framework, is encapsulated within a result factory class.