J2EE design decisions - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 55

Table 2.3 Mary's decisions

Strategy Decision Rationale

Business logic organization Domain Model pattern The business logic is relatively complex.

There does not appear to be any queries that
cannot be handled by the JDO query language.

Database access JDO Using the Domain Model pattern.

Concurrency None This use case does not update shared data.

The order is created at the end of the use
case.
The pending order is session state and is only
updated by this session.

how to persist that domain model with Hibernate, and in chapter 9 you will see
how to implement the same business logic using a procedural approach.

The View Orders use case
Tom is responsible for implementing the View Orders use case:

The customer service representative enters the search criteria. The system dis-
plays the orders that match the search criteria. The customer service representa-
tive can cancel or modify an order.

Tom analyzes this use case and concludes that a key issue is that the order table
will contain a large number of rows and will need to be denormalized for efficient
access. In addition, the queries will need to be heavily tuned and make use of Ora-
cle-specific features. Consequently, Tom decides that he needs to use SQL queries
to retrieve the orders. Table 2.4 summarizes his decisions.

Table 2.4 Tom's decisions

Strategy Decision Rationale

Business logic organization Transaction Script pattern Simple business logic.

Uses iBATIS.

Database access iBATIS Heavily optimized SQL queries using

Oracle-specific features.
Database schema denormalized for
efficient access.

Concurrency None This use case does not update

shared data.