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

As you can see, when using the Spring framework you only need to define a few
Spring beans in order to make a POJO façade transactional and integrated with
the persistence framework. The only drawback is that the Spring bean definitions
can be verbose, especially when compared with EJB 3 annotations. This is, how-
ever, an insignificant price to pay for all of the benefits of Spring.
7.7 Summary
The traditional approach of encapsulating the business logic in a J2EE application
using the Session Façade and DTO patterns has numerous drawbacks. It couples
the business logic to the EJB container, which slows down development and test-
ing. It is also time consuming and tedious to develop and maintain the DTO s and
the code that creates them.
For many applications, a much better approach is to encapsulate the business
logic with a POJO façade. The POJO façade handles requests by calling the under-
lying domain model classes. The POJO façade is deployed in a lightweight con-
tainer such as Spring and uses AOP interceptors to manage transactions,
persistence framework connections, and security. Development and testing is
faster and easier since the POJO façade can run outside the application server. In
addition, because the POJO façade returns data using detached domain objects,
the only DTO s that need to be written are those that aggregate domain objects.
Another benefit is that a POJO façade can be tested with a simple set of tests that
use mock objects for the domain objects that it calls.
In the next chapter, we will look at the Exposed Domain Model pattern, which
is another lightweight alternative to the Session Façade pattern.