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

In the previous chapter, you saw how encapsulating the business logic with a POJO
façade has several benefits, including ease of development and improved main-
tainability. However, one problem with a POJO façade is that the code that
detaches the domain objects returned to the presentation tier is error-prone.
When you're making changes to the presentation tier, it is quite easy for the
detachment code and the presentation tier to get out of sync and for the POJO
façade to only return some of the objects required by the presentation tier. This
can cause subtle bugs that can only be detected by thorough testing.
An alternative approach that avoids this problem is to use the Exposed
Domain Model pattern, which is also known as the Open Session in View pattern
[OpenSessionInView] or the Open PersistenceManager in View pattern. This pattern
exposes the domain model to the presentation tier. The presentation tier calls the
domain services and repositories directly without going through a façade. It also
accesses the persistent domain objects, which means that as it navigates the object
graph, the persistence framework will lazily load any required objects. The busi-
ness tier is simpler and less error-prone because it does not have to detach objects.
However, while this approach avoids the problems of using detached domain
objects, some tricky design issues arise from how transactions, persistence frame-
works, and the servlet API interact.
In this chapter, you will learn how to solve those design issues for both JDO and
Hibernate. We describe how to implement business logic that has an exposed
domain model and show you how to use Spring AOP to manage transactions and
persistence framework connections. You'll also learn about the drawbacks of
using an exposed domain model and when it is not the best solution. Once again,
we'll use the business logic for the Place Order use case as an example.
8.1 Overview of the Exposed Domain Model pattern
It took me a while to accept the value of the Exposed Domain Model pattern. The
first time I heard about this design technique my instant reaction was, “It can't be
right! You must use a façade.” I had a similar reaction the second and third times.
I had become accustomed to encapsulating the business logic with either a session
façade or a POJO façade. Eventually, this approach started to make sense. After all,
if the presentation tier and business tiers are running in the same machine, then
the cost of calls between the tiers is negligible. We do not need to be constrained
by a design approach whose main motivation was to minimize the overhead of
remote calls. We can eliminate the façade, which is just a middleman, and write
less code and not worry about detaching objects. Let's see how this pattern works
and why you would want to use it.