removes the need for false patterns, such as Factory and Singleton, that hinder testing and only partially
solve the problem for which they are designed.
In this section, we present a high-level overview of the design and implementation decisions of the
SpringBlog application with pointers to where each topic is discussed in detail.
Development Tool and Dependency Management
Before going into the design, let's decide how we are going to implement the SpringBlog application. For
developing Spring-based applications, the most appropriate tool is SpringSource Tool Suite (STS). STS
bundles Eclipse IDE, Spring IDE, and a lot of useful tools (such as the Maven plug-in for Eclipse, Mylyn,
AspectJ Development Tool for Eclipse, and so on) into a single package. If you already have a version of
Eclipse installed on your development machine, you can also install STS plug-ins via the STS Eclipse
STS. Details on STS will be provided in Appendix A.
As discussed previously, the entire Spring Framework is composed of many modules, and each
module depends on other Java libraries as well. Although you can sort out the required Spring modules
and third-party dependencies and include them into your project manually, it's much easier to use a
dependency management tool to handle it for you. STS comes with out-of-the-box support with
Maven, a popular application dependency management tool. The SpringBlog application will use
Maven to manage the dependencies, as well as the build life cycle. For version control, Git will be used,
and besides downloading the source code of the sample application from the topic's page, you can also
check out the latest version of the application from GitHub (http://github.com).
Application Design
The design of SpringBlog is very simple, with each tier defined in terms of interfaces rather than concrete
classes. In each tier, the interfaces that correspond to that tier define only the methods exposed by that
tier to other tiers classified as client tiers. Parameters for configuring SpringBlog will not be hard-coded
in the application. Instead, the configuration methods are declared on the classes that implement the
interfaces in each tier, and configuration data is injected using Spring's IoC-based configuration
mechanisms. Chapter 21 presents a full discussion of the different interfaces that make up SpringBlog,
how they are wired together using Spring, and factors affecting interface granularity.
The SpringBlog application also contains a basic Domain Object Model (DOM) that encapsulates
both data and behavior. In Chapter 12, we take the time to look at the different flavors of the DOM you
may have seen in projects that you have worked on, and we discuss the factors you must consider when
deciding whether to encapsulate behavior in the DOM or in separate service objects.
Application Configuration Management
In the SpringBlog application, we will use the latest Spring Framework (at the time of writing, version
3.1) for DI configuration. Starting from version 3.0, Spring supports the configuration management via
either XML files or Java annotations.
For SpringBlog, we will take a mixed approach. First, all the infrastructure setup (for example, the
data source, transaction manager, and so on) will be defined in various XML configuration files for easier
maintenance. For those injectable beans and beans that require DI, we will use Java annotations to
express the DI requirements. Second, the requirements of transaction support will be defined using Java
annotations too. We will then rely on Spring's component scan and autowire features for scanning those
classes for those annotations and manage the beans and their requirements on various resources under
the cover.
Details of Spring configuration topics will be covered in Chapters 4 and 5.
Search WWH :
