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

2.7.2 Making high-level design decisions

After identifying some requirements and sketching out a high-level architecture,
the team needs to make the high-level design decisions that determine the overall
design of the application. In this section, we consider each of the five design deci-
sions that we described earlier and show how a development team might make
those decisions. You will learn about the kind of process that you must use when
designing your application.

Organizing the business logic
The business logic for this application is responsible for such tasks as determining
which restaurants can deliver to a particular address at the specified time, apply-
ing discounts, charging credit cards, and scheduling drivers. The team needs to
choose between an object-oriented approach or a procedural approach. When
making this decision, the team first considers the potential complexity of the busi-
ness logic. After reviewing the use cases, the team concludes that it could become
quite complex, which means that using an object-oriented approach and develop-
ing a domain model is the best approach. Even though it is simpler, using a proce-
dural approach to organize the business logic would lead to maintenance
problems in the future.
The team also briefly looks at the issue of whether they could use a persistence
framework to access the database. Unlike when developing some past applica-
tions, they are not constrained by a legacy schema or the requirement to use SQL
statements maintained by a database administrator ( DBA ). Consequently, they are
free to use a persistence framework and to implement the business logic using a
domain model. However, they also decide that some business logic components
can use a procedural approach if they must access the database in ways that are
not supported by the persistence framework.

Encapsulating the business logic
In the past the team used EJB-based session façades to encapsulate the business
logic and provide transaction management and security. EJB session façades
worked reasonably well except for the impact they have on the edit-compile-
debug cycle. Eager to avoid the tedium of deploying EJB s, the team is ready to
adopt a more lightweight approach. Mary, who has just returned from the TSS
Java Symposium 2005, where she spent three days hearing about POJO s, depen-
dency injection, lightweight containers, AOP , and EJB 3 , convinces the rest of the
team to use the Spring framework instead of EJB s.