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

In this example the presentation tier accesses the objects it needs to generate
the response, such as the restaurant and its menu items, by navigating from the
PendingOrder . However, a POJO façade method often returns multiple domain
objects to the presentation tier. For example, the PlaceOrderFacade defines an
updateDeliveryInfo() method, which returns the PendingOrder and a list of avail-
able restaurants. Consequently, façade methods typically return a DTO -like object
that aggregates several detached domain objects.
We would identify the other POJO façade methods by looking at each transi-
tion between pages in the UI and defining a corresponding POJO façade method.
See this topic's online source code for the complete PlaceOrderFacade .

7.4 Implementing the POJO façade

Once you have identified the methods and defined the POJO façade's interface, the
next step is to develop the POJO façade class that implements the interface. This
class in our example façade implements the PlaceOrderFacade interface and is
called PlaceOrderFacadeImpl . Each POJO façade method defined by this class is usu-
ally quite simple because it does not contain any significant business logic. Instead,
as figure 7.6 shows, it delegates to domain model classes. It also calls the persistence
framework to detach the domain objects required by the presentation tier.
A good way to implement a POJO façade's methods is to use a test-driven
approach that mocks the objects that it calls. This enables you to test only the sim-
ple logic implemented by the façade without worrying about the complex busi-
ness logic implemented by the domain model or, worse, the database. To see how
this is done, let's implement the updateRestaurant() method, which we identified
earlier in section 7.3.1. We will first write some tests and then write the method.

7.4.1 Writing a test for a POJO façade method

Because we are using test-driven development, we first need to write a test for the
updateRestaurant() method. As figure 7.6 shows, this method calls the PlaceOr-
derService to update the PendingOrder with the selected restaurant. It returns the
PlaceOrderFacade result object, which contains the detached PendingOrder .
Unlike some of the other methods defined by PlaceOrderFacadeImpl , updateRes-
taurant() doesn't invoke any repositories.
The updateRestaurant() method returns a PlaceOrderFacadeResult that con-
tains a status code and the detached PendingOrder . The PlaceOrderFacadeImpl
could detach the objects by calling the persistence framework API s directly. How-
ever, this would complicate development and testing because it would be directly