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