Using an exposed domain model - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 294

be difficult to do when using this pattern. Because the presentation tier
freely accesses the domain objects, the interactions between the tiers are
less clearly defined and finer-grained. Either you can optimize each fine-
grained method in isolation, which provides a lot less opportunity to
improve performance, or you have to understand the design of the presen-
tation tier, which complicates the performance-tuning task.

More error handling in JSP pages —Another drawback of exposing the domain
model is that JSP pages might have to contain additional code to handle
exceptions thrown by domain model classes. In a façade-based design, the
façade and servlets handle all exceptions. The JSP pages display the data
contained in DTO s or detached objects whose methods are all simple get-
ters (which access fields and do not throw exceptions). When using the
Exposed Domain Model pattern, a JSP page must be prepared to handle any
exceptions that are thrown by the domain objects that it invokes.

■

No support for remote access —The business tier must expose a coarse-grained
API in order to support remote clients efficiently. It must also return detached
objects because it does not make sense to the remote client to use lazy load-
ing. Consequently, it's not possible for an exposed domain model to support
remote clients. The interface is too fine-grained and the objects are never
detached. If your application must support remote clients, then you must
encapsulate the business logic with either a POJO façade or an EJB façade.

■

The two ways in which you can manage transactions when using this pattern have
other potential drawbacks. But first, let's look at when to use this pattern.

8.1.3 When to use the Exposed Domain Model pattern

Despite these drawbacks, the Exposed Domain Model pattern is a good way to
design certain JDO and Hibernate applications. You should consider using an
exposed domain model when:

The business logic's client can manage the persistent framework connection.

■

The business logic does not need to be accessed remotely.

■

You also need to consider the potentially tricky transaction management issues
that are described in section 8.3. But before getting to that, let's first look at the
details of managing connections in a Spring application.