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

Presentation
Tier

<<interface>>
PlaceOrderFacade

PlaceOrderFacadeResult updateRestaurant(pendingOrderId, restaurantId)
...

PlaceOrderFacadeImpl

PlaceOrderFacadeResult updateRestaurant(pendingOrderId, restaurantId)
...

Domain

PlaceOrder
Service

PendingOrder Persistence

Framework

Figure 7.6 The PlaceOrderFacade and its relationship with the rest of the application

coupled to the persistence framework and the database. A better design, which
simplifies testing, is to encapsulate the detachment logic behind what I call a
result factory.
The result factory interface in this particular example is called PlaceOrder-
FacadeResultFactory . It defines a make() method that takes a status code and Pend-
ingOrder as parameters. This method detaches the PendingOrder and returns a
PlaceOrderFacadeResult . PlaceOrderFacadeResultFactory provides an easy-to-
mock interface that makes testing the PlaceOrderFacade simpler. It also improves
reusability by decoupling the PlaceOrderFacade from the persistence framework.
Now that we have figured out how this method works, let's write a test.
Listing 7.1 shows a test that uses JM ock to verify that this method behaves as
expected. The test case class extends MockObjectTestCase and creates mock imple-
mentations of the PlaceOrderService and the PlaceOrderFacadeResultFactory .

Listing 7.1 PlaceOrderFacadeMockTests

public class PlaceOrderFacadeMockTests extends MockObjectTestCase {

private Mock mockPlaceOrderService;
private Mock mockResultFactory;