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

inconvenient for the user to start over if some other user changed the order
while she was editing it, Wanda decides to use the Pessimistic Offline Lock pat-
tern. Table 2.7 summarizes Wanda's decisions.

Table 2.7 Wanda's decisions

Strategy Decision Rationale

Business logic organization Domain Model pattern Complex business logic.

Database access JDO Using the Domain Model pattern.

Concurrency Optimistic locking The use case updates orders, which

consist of shared data.

Offline concurrency Pessimistic Offline Lock

pattern

The use case reads the order in one
transaction and updates it in another.
The cost of starting over is high.

Wanda plans to meet with Dick and Harry to reconcile their respective concur-
rency requirements.
Chapter 13 looks at the different ways of implementing this use case.

2.8 Summary

This chapter describes how the task of designing the business and persistence
tiers can be broken down into five main design decisions: organizing business
logic; encapsulating business logic; accessing the database; handling database
transaction-level concurrency; and handling concurrency in long-running trans-
actions. Each decision has multiple options, and each option has benefits and
drawbacks that determine whether it makes sense in a particular situation.
These decisions play a critical role in helping you decide between a POJO
approach and a heavyweight EJB 2 approach. Some decisions have POJO options
and heavyweight options. For example, you can encapsulate the business logic with
a POJO façade or an EJB session façade. Other decisions have options that are made
easier by using the POJO approach. For example, as we described in chapter 1, the
heavyweight approach favors business logic that is organized procedurally, whereas
the POJO approach enables you to use an object-oriented design.
Now that we have reviewed the design decisions and their options, let's exam-
ine each one in depth. In the next chapter, we first look at how to implement busi-
ness logic using the Domain Model pattern.