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

The other option is for each POJO façade method to make sure that the
objects required by the presentation tier are loaded by either navigating to them
or by calling Hibernate.initialize() . The initialize() method takes either an
object or a collection as a parameter and ensures that it is loaded. A POJO method
façade could, for example, force the pending order's restaurant and its menu
items to be loaded using code such as this:

Hibernate.initialize(pendingOrder.getRestaurant().getMenuItems());
A benefit of this approach is that a POJO façade method knows precisely what
objects will be needed by the presentation tier and can ensure that they are
loaded. The drawback is that it requires code, which must sometimes contain con-
ditional logic to handle null references and polymorphic references. For exam-
ple, if the reference to a restaurant could be null, you need to write code such as
this to avoid NullPointerException s:

Restaurant r = pendingOrder.getRestaurant();
if (r != null)
Hibernate.initialize(r.getMenuItems());
This code can sometimes get quite complicated. Moreover, it can be difficult to
maintain because the structure of the object graph is hardwired into the façade.

7.2.3 Exceptions versus status codes

Another decision you need to make is whether the facade should use exceptions
or status codes to communicate errors to its caller. There are often many possible
outcomes of calling a façade method. For example, PlaceOrderFacade.update-
DeliveryInfo() normally updates the PendingOrder , but several things could go
wrong. There are, for instance, various application-level errors, such as delivery
information that is not served by any restaurants or a delivery time that is not far
enough in the future. Various infrastructure-level errors can also occur, including
database crashes or deadlocks. A POJO façade should certainly report an infra-
structure error to its caller by throwing an exception, but what about application-
level errors?
One option is to return a DTO for the “normal” outcome and to throw an
exception for the other outcomes. One appealing feature of exceptions is that the
Spring TransactionInterceptor can be configured to automatically roll back the
transaction when an exception is thrown (as you will see later in this section). The
code does not have to programmatically roll back the transaction, which would
have the undesirable side effect of coupling the code to the Spring framework.