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

provides role-based declarative security. In addition, if the session bean has a remote
interface, it can be invoked remotely and participate in distributed transactions.
One drawback, however, of using EJB s is that they are more difficult to test
than Spring beans because they must be deployed in the EJB container. For exam-
ple, in order to test an EJB through its local interface you would have to imple-
ment the tests using Cactus [Cactus] and deploy them in the application server as
well. In addition, deployment is, as we've mentioned earlier, an extra step that can
slow down the edit-compile-debug cycle. In comparison, you don't have jump
through these kinds of hoops to test Spring beans.

10.3.2 Detaching objects

In addition to managing transactions, a façade is responsible for detaching persis-
tent objects so that they can be used by the presentation tier. EJB 3 , like Hibernate,
automatically detaches all objects that were loaded during the transaction, and so
the façade must simply ensure that all of the objects required by the presentation
tier are loaded. Sometimes, the domain model services and repositories called by
the façade will load the required objects. However, because of lazy loading those
domain model classes often return an incomplete object graph and so a façade
must sometimes force objects to be loaded.
A Hibernate application can force an object or collection to be loaded by call-
ing Hibernate.initialize() . However, the EJB 3 EntityManager does not define
the equivalent of Hibernate.initialize() , which means the application must
traverse the object graph and touch the required objects and collections. As with
the POJO façade we saw in chapter 7, we can encapsulate this logic inside a result
factory class that loads the required objects and creates the DTO that is returned
by the façade.
For example, PlaceOrderFacade can use the implementation of the Place-
OrderFacadeResultFactory interface shown in listing 10.4 to do this. EJB3Place-
OrderFacadeResultFactory ensures that the PendingOrder 's line items and restau-
rant are loaded before creating the PlaceOrderFacadeResult .

Listing 10.4 EJB3PlaceOrderFacadeResultFactory

public class EJB3PlaceOrderFacadeResultFactory
implements PlaceOrderFacadeResultFactory {

public EJB3PlaceOrderFacadeResultFactory() {

}