Java Reference
In-Depth Information
Applications should also be able to able to use this pattern with
EJB 3
. The serv-
let filter uses an
EntityManagerFactory
to create an
EntityManager
, and transac-
tions are managed using
EntityTransaction
. Unfortunately, however, at the time
of this writing Spring does not yet provide support
EJB 3
and so I haven't been
able to try it.
10.5.2
Implementing the Transaction Script pattern
As you saw in chapter 9, it sometimes makes sense to implement business logic
using the Transaction Script pattern instead of the Domain Model pattern. The
Transaction Script pattern organizes the business logic as a set of procedural
transaction scripts that call
DAO
s to access the database. The
DAO
s access the
database using either
JDBC
or a higher level, easier to use
API
such as Spring's
JDBC
classes or i
BATIS
.
There are a couple of ways to implement the transaction scripts in an
EJB 3
application. One option is to implement the transaction scripts class and the
DAO
s as stateless session beans, as shown in figure 10.6. This diagram shows the
EJB 3
version of transaction script example from chapter 9.
In this example,
PlaceOrderTransactionScripts
,
PendingOrderDAO
, and
Res-
taurantDAO
are implemented as stateless session beans.
EJB 3
dependency injec-
tion is used to wire together these components along with the
JDBC
DataSource
.
Using this approach is straightforward if the
DAO
s use
JDBC
directly because
the
EJB
container simply has to inject the
DataSource
, which is a standard J2EE
resource, into each
DAO
. However,
DAO
s often use a higher level, easier to use
API
such as a Spring
JdbcTemplate
or
SqlMapClientTemplate
. In order for the
EJB
con-
tainer to inject these classes into a
DAO
, the Spring beans must be bound to
JNDI
,
as we described in section 10.4.2.
The other option is to implement the
DAO
s as
POJO
s and to create them using
Spring. The transaction scripts
EJB
calls Spring to instantiate the
DAO
s, which
inject the
JdbcTemplate
or
SqlMapClientTemplate
class. The downside of this
approach is that the explicit calls to Spring make the transaction scripts more dif-
ficult to test.
10.5.3
Implementing dynamic paged queries
In chapter 11 we describe how to implement dynamic paged queries, which are
used to retrieve data that is displayed on search screens. Search screens allow the
user to enter search criteria and view the result set, which is often too large to load
into memory, let alone display on a single screen. Consequently, the user must be
able to page through the result set. Also, because the database is typically large it's
Search WWH ::
Custom Search