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

The servlet and JSP page call the domain model objects directly. UpdateDelivery-
InfoServlet calls PlaceOrderService to update the PendingOrder and calls Res-
taurantRepository to retrieve the list of available restaurants. It passes the
PendingOrder and the restaurants to the JSP page restaurants.jsp, which uses them
to generate the HTML page that displays the available restaurants.
In this design, transactions are managed by a Spring TransactionInterceptor ,
which intercepts calls to the PlaceOrderService , but another option is to manage
transactions using a servlet filter. In section 8.3, we will explain the benefits and
drawbacks of these two approaches to transaction management. But first let's look
at the overall benefits and drawbacks of using the Exposed Domain Model pattern.

8.1.2 Benefits and drawbacks of this pattern

The Exposed Domain Model pattern has several benefits and drawbacks:

Faster development —An important benefit of this pattern is that it accelerates
development. There is less code to write because the business tier does not
contain façades or error-prone detachment logic. Development is also faster
because, unlike an EJB session façade, the business logic uses POJO s and can
be developed and tested outside the application server.

■

Potentially eliminates the need for an EJB container —Many applications use an
EJB container only because they encapsulate the business logic with session
façade EJB s. Consequently, this pattern potentially eliminates the need to
use an EJB container.

■

Less encapsulation —One problem with this pattern is the lack of encapsula-
tion. Because there isn't a façade to clearly define the API between the pre-
sentation and business logic, it is quite easy for business logic to creep into
the presentation tier. Consequently, developers using this design approach
must periodically review and refactor their code to ensure that the business
logic and presentation logic are kept separate. Furthermore, as with the
POJO façade approach described in chapter 7, the presentation tier has
access to the domain objects. It could, for example, update them directly
without going via a domain service. There is also a greater chance of
changes to the business logic impacting the presentation tier. Luckily, you
can reduce the risk of these problems occurring by encapsulating the
domain objects with view interfaces and adapters.

■

More difficult to optimize the business tier —Ideally, we should be able to opti-
mize the performance of the business and persistence tiers without worry-
ing about the presentation tier. But optimizing those tiers in isolation can

■