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

queries. However, while fetch joins are a concise and easy-to-use way to dynamically
control eager loading, they have some limitations.
As you saw in chapter 6, one important limitation of Hibernate-style fetch joins
is that because they are part of the query language they cannot control eager load-
ing when loading an individual object or traversing a relationship. Also, if differ-
ent use cases need to eagerly load different sets of objects, an application must use
multiple variants of a query, each one with a different set of fetch joins. This can
make it difficult to implement a repository that is shared by different business
logic components because it must provide multiple query methods or a single
query method that has a parameter that indicates which fetch joins to use. Conse-
quently, you will encounter the same issues with optimizing an EJB 3 application as
you will with a Hibernate application.
Limitations of automatic detachment
Detached objects are another important EJB 3 feature. But the lack of a declara-
tive fetch group mechanism in EJB 3 can make it difficult to detach the necessary
objects. In EJB 3 , the EJB container automatically detaches all objects that were
loaded by the application. Unlike JDO , an application cannot use fetch groups to
specify which objects to detach. If different business methods need to return dif-
ferent object graphs, an EJB 3 application has two options. One option is to use
multiple queries with different fetch joins, which compounds the problem with
eager loading that we described earlier. Another option is to navigate to each of
the required objects, which is tedious and error-prone and embeds the object
structure in the application's code. In comparison, a JDO 2.0 application can use
fetch groups to declaratively specify which objects to return.
Dependency injection can only inject JNDI objects into EJBs
A façade, which is typically implemented as a session or message-driven bean, usu-
ally depends on one or more other components, which in turn depend on other
components. For example, the PlaceOrderFacade depends on components such
as the PlaceOrderService and the RestaurantRepository . Ideally, we should be
able to use EJB dependency injection to wire all of these components together.
However, one of its big limitations is that it can only inject JNDI objects into EJB s.
It will not wire together POJO s such as domain services and repositories and inject
their dependencies. Later in this chapter we describe how to solve this problem. It
is disappointing, however, that EJB 3 does not support dependency injection of
POJO s or provide some kind of integration with a lightweight framework con-
tainer such as Spring.