Implementing POJOs with EJB 3 - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 400

PlaceOrderFacadeResultFactory.class);

this.service = (PlaceOrderService) TheBeanFactory
.getBean("PlaceOrderService",
PlaceOrderService.class);
}
…

The createComponents() method calls TheBeanFactory , which is a helper class that
wraps a Spring BeanFactory , to create the components that the PlaceOrderFacade
EJB needs. The @PostConstruct annotation specifies that the EJB container must
call this method after it has instantiated the EJB . The Spring beans used by the
PlaceOrderFacade would be configured in the same way as the previous example.
As this example shows, having the session bean call the Spring framework
enables the application to use dependency injection with arbitrary objects. The
downside is that the EJB must make explicit calls to Spring, which is extra code
that must be written and maintained. In addition, the dependency of the EJB on
Spring makes it more difficult to test. However, this approach is useful if your
application needs to use some functionality that is not provided by the EJB con-
tainer and that is only available in Spring.

10.5 Implementing other patterns with EJB 3

So far in this chapter we have looked at how to use EJB 3 to implement a domain
model that is encapsulated by a session façade. There are, of course, other design
options, such as the Exposed Domain Model pattern and the Transaction Script
pattern. In addition, you must consider other issues when developing the business
tier with EJB 3 , issues such as database concurrency and efficient database queries.

10.5.1 Implementing the Exposed Domain Model pattern

In chapter 8 we described the Exposed Domain Model pattern, in which the pre-
sentation tier makes direct calls to the domain model without going through a
façade. An application that uses this pattern has a servlet filter that opens and
closes the JDO PersistenceManager or Hibernate Session . Each call to a domain
service occurs in a transaction, and when the presentation tier generates the
response, it accesses the persistent objects outside of a transaction. This pattern is
useful because you don't have to develop a façade or worry about detaching the
objects that are required by the presentation tier.