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

In the design in figure 2.6, the presentation tier calls the domain objects directly
without going through a façade. Spring AOP continues to provide services such as
transaction management and security.
An important benefit of this approach is that it eliminates the need for the
business tier to know what objects it must load and return to the presentation tier.
However, although this sounds simple you will see there are some drawbacks. It
increases the complexity of the presentation tier, which must manage database
connections. Transaction management can also be tricky in a web application
because transactions must be committed before the presentation tier sends any
part of the response back to the browser. Chapter 8 describes how to address these
issues and implement an exposed domain model.

2.4 Decision 3: accessing the database

No matter how you organize and encapsulate the business logic, eventually you
have to move data to and from the database. In a classic J2EE application you had
two main choices: JDBC , which required a lot of low-level coding, or entity beans,
which were difficult to use and lacked important features. In comparison, one of
the most exciting things about using lightweight frameworks is that you have some
new and much more powerful ways to access the database that significantly reduce
the amount of database access code that you must write. Let's take a closer look.

2.4.1 What's wrong with using JDBC directly?

The recent emergence of object/relational mapping frameworks (such as JDO
and Hibernate) and SQL mapping frameworks (such as i BATIS ) did not occur in a
vacuum. Instead, they emerged from the Java community's repeated frustrations
with JDBC . Let's review the problems with using JDBC directly in order to under-
stand the motivations behind the newer frameworks. There are three main rea-
sons why using JDBC directly is not a good choice for many applications:

Developing and maintaining SQL is difficult and time consuming —Some devel-
opers find writing large, complex SQL statements quite difficult. It can also
be time consuming to update the SQL statements to reflect changes in the
database schema. You need to carefully consider whether the loss of main-
tainability is worth the benefits.

■

There is a lack of portability with SQL —Because you often need to use database-
specific SQL , an application that works with multiple databases must have
multiple versions of some SQL statements, which can be a maintenance

■