Demonstrating Spring's Finesse

Author's note: In this excerpt from Chapter 8 of our book, Better, Faster, Lighter Java, we look at an example of an enterprise web application using the Spring framework. While Hibernate provided a single service, the Spring framework provides an efficient way to build and assemble Java applications, with abstractions for many services. Although it supports many services, Spring stays focused and clean with excellent layering and encapsulation. Like EJB, the centerpiece for Spring is a container, and like EJB, the Spring framework provides access to core J2EE services. But that's about as far as any similarities go. Here's a metaphor.

I love to kayak and spend a lot of time teaching kayaking skills. One of my specialties is teaching students how to roll an upside-down kayak in white water. One day, I was teaching this skill to a muscle-bound hulk and a dainty little 97lb woman. While I talked through the technique on dry land, Meathead stared into the distance, disinterested. The woman focused well and wanted to practice the foundation techniques over and over. Within a half an hour, she hit her first roll incredibly well, while he was just thrashing about, whipping the calm water into fine white foam. He didn't come close until his third session. In sessions to come, she relied on her technique to improve quickly; he relied on strength, and floundered. When it was time to put the skills into practice, she rolled while he swam. Programmers, take note: it's usually better to solve problems with simplicity and finesse rather than muscle.

Pet Store: A Counter-Example

The J2EE Pet Store application is an infamous programming example
gone bad. It taught thousands of J2EE developers to build poorly
designed, poor-performing code. It was also the center of a
benchmarking controversy. A respected consulting company called The
Middleware Company worked on a benchmark comparing J2EE with
Microsoft's .NET platform. As a foundation for the
benchmark, they chose the J2EE version of Pet Store. Though they
worked hard to tune it, the J2EE version lost badly to the Microsoft
.NET version and many criticized the design. I don't
intend to lay any blame for this fiasco. Instead, I offer a different
interpretation. It's my firm opinion that J2EE,
especially EJB, makes it hard to develop clean, high-performance
code. Put another way, the Pet Store benchmark was a symptom of a
larger problem.

After the benchmarking uproar, a number of people showed how to
implement Pet Store with easier, simpler technologies. One of the
strongest and simplest implementations, by Clinton Begin, used a DAO
framework called iBatis instead of full entity beans. Rod
Johnson's team converted that application to Spring,
and now distributes it with the Spring framework. Here are some of
the details:

It provides alternative frontends for Struts, and the Spring MVC framework.

It provides two different models. The simplest uses a single database and simple JDBC transactions. The other uses JTA transaction management across multiple data stores.

In the following sections, I'll work through the
version of the application with the MVC web frontend and simple
transactions across one database. I'll focus on the
domain model, the single-database DAO layer, simple transactions, and
the Spring MVC frontend. Outstanding resources are available at the
Spring web site for those who want to dive deeper.

The Configuration

When learning a Spring application, start with the configuration file; it shows you the major beans and
how the application fits together. A Spring configuration file
defines the beans in an application context. Think of the context as
a convenient collection of named resources for an application.

Many J2EE applications keep track of application resources such as
connections and the like with singletons. When you think about it, a
singleton used in this way is not much different from a global
variable; many Java developers lean on this crutch too often.
J2EE's alternative is a directory service called
JNDI, but it's overkill for many common uses.
Spring, instead, uses an application context. Initially, you specify
it in a simple XML file, although you can extend Spring to accept
other kinds of configuration as well. Here are some of the things
that might go into an application context:

Data sources

A Java class that manages connections, usually in a pool.

DAO layers

If your applications use a database, you probably want to isolate the
database access to one layer, the DAO. You can access this layer
through the application context.

Persistence managers

Every persistence framework has an object or factory
that the application uses to access its features. With Hibernate,
it's the session and the session factory. With JDO,
it's the persistence manager factory and persistence
manager.

Transaction policies

You can explicitly declare the methods
that you want to participate in transactions and the transaction
manager that you want to use to enforce that strategy.

Transaction managers

There are many different transaction management strategies within
J2EE. For single database applications, Spring lets you use the
database's transaction management. For multiple
databases or transaction sources, Spring allows JTA instead. You can
keep the transaction manager in the application context.

Validation logic

The Spring framework uses
a validation framework similar to Struts. Spring lets you configure
validation logic like any other business component.

Views and controllers

The Spring framework lets you specify the controllers for a view and
helps you configure the navigation path through them.

The jPetStore application uses the Spring
application context for a data source, the DAO layer, and a
transaction strategy. You define what goes into a context within an
XML document that lists a series of beans. Each XML configuration
file will have a <beans> heading, followed
by a series of <bean> components, and a
</beans> footer, like this:

These are the beans that make up an application context. They
represent the top-level beans of an application. (They may create
other objects or beans that do not appear in the configuration file.)
In this case, you create two beans named
MyFirstBean and MySecondBean.
Then, you wire them together by specifying
MySecondBean as the value for the field
myField. When Spring starts, it creates both
objects and sets the value of myField. You have
access to both of these objects by name whenever you need them
through the application context.

Let's look at a more concrete example. The
jPetStore application has three configuration
files for the business logic, the data layer, and the user interface,
as in Figure 8-2. A separate Spring configuration
file describes each one.

Figure 8-2. The jPetStore application has Spring application contexts to match its three distinct layers

These configuration files specify the context for the domain model, the data layer, and the presentation layer. Example 8-1 shows part of the application context for the business logic of the jPetStore application. Note that I've shortened the package name from org.springframework.samples.jpetstore... to
jpetstore for simplicity.

[1]Business logic. This section (which includes all bold code) has the core business logic. Validation and the domain model are both considered business components.

[2]Validators. This is the validator for Order. Spring calls it whenever a user submits the Order form and routes to the error page or an order completion page, as required.

[3]Core business implementation. This class contains the core implementation for the persistent domain model. It contains all of the DAO objects that you'll see below.

[4]Properties. Each of your beans has individual properties that may refer to beans you define elsewhere. In this case, the bean properties are individual DAO. Each of these beans is defined in another Spring configuration file.

[5]Transaction declarations. This bean specifies the transaction strategy for the application. In this case, the application uses a transaction manager specified in another Spring configuration file. It declares the methods that should be propagated as transactions. For example, all methods beginning with insert should be propagated as transactions.

In short, this configuration file serves as the glue that holds the
business logic of the application together. In the file, you see some
references to beans that are not in the configuration file itself,
such as the DAO objects. Later on, you'll see two
other configuration files that define some of the missing beans. One
specifies the data access objects with the transaction manager. The
other specifies the beans needed by the user interface.
It's often better to break configuration files into
separate layers, allowing you to configure individual layers as
needed. For example, you may want to change strategies for your user
interface (say, from Spring MVC web to Struts) or for data access
(say, from DAO with one database to DAO spanning two databases with
JTA transactions).

If you want to instantiate a bean from your XML context file,
it's easy. For example, in order to access a bean
called myCustomer of type
Customer from a file called
context.xml, take the following three steps:

Get an input stream for the XML file with your configuration:

InputStream stream = getClass( ).getResourceAsStream("context.xml");

Create a new Spring bean factory using the input stream:

XmlBeanFactory beanFactory = new XmlBeanFactory(stream);

Use the factory to create one of the objects defined in your .xml file:

Customer cust = (Customer)beanFactory.getBean(myCustomer);

Or, if you want Spring to initialize a context and then grab, for
example, your session façade, you'd use
code like this:

It's often better to let go of that control.
Usually, you won't have to access the application
context directly. The framework does that for you. For example, if
you're using servlets, the Spring framework provides
a context for each servlet and a catch-all context for servlets. From
there, you can usually get the appropriate context information, as
you'll see later. Now that you've
seen a configuration file representing the
jPetStore application, it's time
to see how to build the individual
elements.

The Domain Model

In keeping with the principles in the book, the foundation of the
application is the transparent domain model in Figure 8-3. The domain model contains the business
relationships of objects that represent the real world. Pet Store is
made up of carts and orders that contain items.

Figure 8-3. The center of an application is the domain model

The application represents a simple pet store. It consists of a
shopping cart containing cart items, which feeds an order containing
line items. Items consist of products organized into categories. Each
object is a transparent business object implemented as a Java bean
with some properties and some business methods. Example 8-2 shows a CartItem.
I've eliminated the imports and package detail, for
brevity.

[1] The Spring framework does not force components to inherit from a Spring class. They are fully transparent, and can live outside of the container for testing purposes, or if Spring would some day
prove inadequate.

[2] Each field is wrapped with get and set methods, so that Spring can configure them through Java reflection. (Spring can alternatively configure them through constructors.)

[3] Unlike many EJB applications, it's often helpful to include business domain logic within the domain model.

I call this model passive. It's invoked entirely by objects outside of its domain and has coupling
only to other objects within the domain. Notice that it is not merely
a value object, although it does have private properties and public
fields It has business methods to calculate the total price and
increment the quantity. This design makes this business object easy
to understand and reuse, even though the overall design may evolve.
As we move into persistence, you'll see other parts of the model as well.

Next week in the conclusion to this two-part series on Spring, excerpted from Better,
Faster, Lighter Java, the authors will take you through adding persistence to their Pet Store example, and take a look at the area of presentation logic in the Spring framework.