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

7.2 POJO façade design decisions

When designing a POJO façade, you must decide how to encapsulate and detach
domain objects, manage transactions, and support remote clients. Let's look at
each one of these issues in turn.

7.2.1 Encapsulating the domain objects

We have seen that one potential drawback of returning domain objects to the pre-
sentation tier is that it could call methods to update the domain objects without
going via the façade or service. It could also call methods that try to access an exter-
nal resource such as the database, which would throw an exception because the
database connection was closed. For example, a JSP page that displays a Pending-
Order could call methods such as updateDeliveryInformation() or update-
Restaurant() that update the pending order.
For some applications, the best way to deal with these problems is to simply
rely on the presentation tier developers to do the right thing. This can work
quite well for smaller projects, especially when the presentation logic and the
business logic are implemented by the same developer. But with other applica-
tions it's important to encapsulate the domain objects and prevent them from
being used inappropriately.
One option is to use Java's visibility rules and define only those methods that
are callable by the presentation tier to be public. But since the business logic usu-
ally consists of multiple packages, we can rarely use this approach. We must
instead encapsulate the domain objects behind interfaces that define read-only
views of domain objects. The presentation tier is written in terms of these inter-
faces rather than the domain model classes. These interfaces can either be imple-
mented by the corresponding domain objects or by an adapter, which is a class
that delegates to the domain object. Let's look at how these two approaches work.

Implementing the interfaces with domain objects
Imagine that you want to implement a JSP page that displays a PendingOrder , its
restaurant, and its line items. If the JSP page accessed those classes directly, it
could call several methods that should only be called by the business tier. A better
approach is to define an interface that specifies the methods that are available to
the JSP page. The JSP page is written in terms of this interface, which is imple-
mented by the PendingOrder class:

interface PendingOrderDetail {
public Address getDeliveryAddress();