abstract model of the data in an application's problem domain. By creating a DOM
for your application, you are creating a set of objects for modeling application data
and behavior that matches some abstract ideas of your problem domain.
The data access layer: Most applications nowadays need to access some kind of
·
persistent data store, typically a relational database. Chapters 8 through 11
discussed Spring's support for a variety of different data access methods. In this
section of the chapter, we look at the design issues related to building a data
access layer to service the rest of your application.
Building the service layer: An application's service layer is where all of the business
·
logic that makes up the application is encapsulated. In this section, we look at how
the service layer interacts with the Domain Object Model and data access layer to
provide a unified interface to access application functionality. We also look at the
business requirements of the SpringBlog application and how this translates into
an interface design and an implementation of that interface.
You should note that this chapter does not cover the design or implementation of the application's
web tier; that is covered in greater detail in Chapters 17 and 18. In particular, we do not cover how the
SpringBlog service layer is utilized by the web frontend, nor do we explore how Spring uses the
validation logic to support data validation and error reporting in the frontend. Both of these topics are
covered in Chapters 17 and 18.
Designing to Interfaces
Designing to interfaces is a common practice when architecting and implementing an application, no
matter which framework or standard (Spring, JBoss Seam, Guice, EJB, and so on) you are working on.
One of the main design goals of Spring is to further ease the development of applications that are
designed and implemented around a set of well-defined interfaces. Before we can look at designing a
Spring-based application in any detail, we should explore exactly why designing to interfaces is such a
big thing and how Spring goes about making it easier.
Why Design to Interfaces
There are many reasons you should design and code your applications to interfaces rather than to a
concrete class hierarchy, but perhaps the biggest reason is to reduce coupling. If components in your
application communicate with each other in terms of interfaces rather than concrete types, it becomes
very easy to swap out a component if it becomes problematic. This capability allows you to switch
from one implementation to another, without having to touch the rest of the application code; indeed,
it is possible for your application to work with many different implementations of the same interface
without even being aware that it is doing so. For example, when using profile support in Spring, you
can provide different concrete implementations of the same interface, without any impact on the rest
of the application.
Remember also that, in Java, a class has only one shot at concrete inheritance but can implement as
many interfaces as necessary. By defining application components in terms of interfaces rather than
classes, you are not going to constrain an implementing class to a particular base class unnecessarily.
One other benefit, as we discussed in Chapter 7, is that using interfaces makes it possible to adopt AOP's
introduction support to "mix in" specific interfaces into target beans when addressing cross-cutting
concerns, without introducing additional complexity into the source code of the target components.
On the testing side, one of the main benefits gained by this loose coupling is the increase in testability.
As the heads of a busy development team, we are constantly seeking new ways to improve the test
coverage in the applications we produce as a direct way of improving the quality of the product we send to
Search WWH :
