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

access control throughout an organization. Obviously, only EJB s can use the EJB
container to provide security, so if you want to secure your POJO façade what can
you do?
As you would expect, the open source community has responded to this need
and developed Acegi Security. Acegi Security [Acegi] is an open source security
framework for Spring. It uses Spring AOP to provide security for Spring beans. How-
ever, one drawback of using something like Acegi Security is that it is potentially less
mature than the security framework provided by the application server. Moreover,
while Acegi Security is integrated with some other security products, it might not be
integrated with the same ones that are available via the application server.
Client must be able to get the façade from the container
Because a POJO façade relies on AOP interceptors to manage transactions and con-
nections, its client must get the façade from the lightweight container. This isn't a
problem for a web-based presentation tier, which might even be tightly integrated
with the lightweight container. But some clients might not be able to call the light-
weight container. For example, a web services code generator, which generates
code that exposes the façade as a web service, needs to know how to instantiate the
façade. If the code generator has no knowledge of the lightweight container, which
is responsible for creating the façade and applying AOP interceptors, it would not
be able to generate code that obtains the correct reference to the façade.
Detaching objects is potentially complex and fragile
Detached objects and POJO façades can be used independently. A POJO façade
can return DTO s, and a session façade can return detached objects. But since
POJO s and ORM frameworks that support detached objects go hand in hand, you
will most likely use them with a POJO façade. The façade must detach all of the
objects that the presentation tier will potentially access, which, as you will see later,
can require careful coding and is potentially error-prone.
To see why, consider the following example. To enable the presentation tier to
render a page that displays a PendingOrder and its line items, the business tier must
detach those objects. But a developer easily could change that screen to display the
restaurant's name in some situations without changing the business tier. Because it
is not possible to catch this problem at compile time, this can all too easily cause
hard-to-reproduce runtime errors. Although later on I describe ways to minimize
this problem, you often have to rely on extensive testing to catch bugs.