Overview of the Spring Modules

Now that we have seen a very high-level preview of Spring, let's look at a brief description of each module. First, we will begin with the two most important modules and then look at the remaining ones in an alphabetical order. Again, we will use only a subset of the modules described next, so do not get overwhelmed by how extensive this framework is.

Spring Core

The core module is essentially the foundation for Spring. It provides fundamental features such as dependency injection (which we will look at later in the chapter) and management of beans. Some of the top-level packages that fit under this module are org.springframework.beans, org.springframework.core, and org.springframework.util.

Spring Context

The context module is perhaps the second most important module in Spring, after the Spring Core module. It contains key classes such as ApplicationContext (explained later in this chapter) and WebApplicationContext, which we will use in Time Expression (loaded from our timex-servlet.xml file, which is explained in the next chapter). In addition, we will use the org.springframework.mail (for sending emails) and org.springframework.validation (for validating web UI fields) packages, which are also considered part of this module.

Other packages, primarily used for remote/distributed functionality (EJB and JNDI, for example), are outside the scope of this book.

Spring AOP

We will not write AOP code directly using Spring. However, indirectly we will end up using Spring AOP-based facilities, such as interceptors for our web application and declarative transaction management. In fact, the Spring reference documentation mentions the same point; that is, if the prepackaged functionality provided in Spring is sufficient for your needs, you do not need to use Spring AOP (to write custom aspects, for example).

Personal Opinion: Projects Not Ready for AOP

Aspect-Oriented Programming (AOP) in some ways is a whole new world, even though it complements OO. Like many other creative innovations, the AOP concept originated at Xerox PARC. Gregor Kiczales originated the AOP concept and, along with his team, also developed AspectJ, the first AOP language and probably still the most popular, or at least the most feature-rich AOP framework or toolkit available today.

AOP essentially provides a cleaner way of modularizing an application into distinct parts (known as separation of concerns). Each layer of an application (business object layer, for example) focuses on its core functionality and does not contain overlapping functionality with other layers. Things such as logging, security, transaction management, and testing are the most common examples of concerns that can easily be separated from the business object layer, for example, via the use of interceptors.

Typically, an implementation of an AOP language seeks to encapsulate these types of crosscutting concerns (such as logging, security, transactions) through the introduction of a new construct called an aspect. An aspect can alter the behavior of the base code (the non-aspect part of a program) by applying advice (additional behavior) over a quantification of join points (points in the structure or execution of a program), called a pointcut (a logical description of a set of join points).

Although AOP offers some obvious advantages and holds a lot of promise for the way we modularize our software applications (using separation of concerns), in my personal opinion, a majority of the software projects are not ready for AOP; hence, it won't become mainstream for another one to two years. Furthermore, I find that AOP's fundamental problem is its core terminology. Terms such as concern, advice, jointpoint, pointcut, and aspect will take many developers some time to adjust to.

Granted, this sounds like a silly reason, but I have always felt that people need to feel comfortable with the basics of a new technology or approach before moving to a more advanced level.

Again, this is my personal opinion and not the state of AOP in the industry, because AOP as a technology is ready and can significantly help your projects if applied correctly.

Spring DAO

Because we are already using Hibernate for database persistence, we do not need this module. However, this module is worth checking out if you like, or need, to work with JDBC but don't like all the tedious try-catch-finally blocks, opening/closing connections, and more. In addition, Spring goes one step further by providing a consistent exception hierarchy, which can convert vendor-specific checked exceptions into more consistent runtime exceptions that can be caught only in the layer of your application you want and ignore it in other places (thereby eliminating the need for cumbersome try/catch/finally code blocks).

Spring for Persistence

It is important to realize that Spring provides a complete persistence functionality. In other words, you could use Spring without an ORM product such as Hibernate and still get the benefits of an easier and cleaner persistence mechanism than plain JDBC (although it won't provide some of the benefits of ORM frameworks that we discussed in Chapter 5, "Using Hibernate for Persistent Objects").

In addition, you get a consistent exception-handling mechanism and other related benefits. We are using ORM framework because so we can work with database records as Java objects.

Spring ORM

Spring's Object-Relational Map (ORM) module provides integration support for popular ORM products used by Java developers, such as Hibernate, JDO, Oracle TopLink, Apache OJB, and iBATIS SQL Maps.

Some of the benefits of using Spring's ORM support include ease of testing (via dependency injection), common data exceptions, persistent resource management (for example, Hibernate's SessionFactory), integrated enterprise-class transaction management, and more.

Spring Web and Web MVC

Among all the Spring modules mentioned here, the web modules are where we will spend the most time in this book. However, we will work with only a few of the classes and packages. For example, we will not have a need for packages that support Sun Microsystem's JavaServer Faces (JSF) standard and others.

Some examples of classes found in these packages, and applicable to Time Expression, are SimpleUrlHandlerMapping, InternalResourceViewResolver, SimpleFormController, Validator, and many others. We will look at these and other classes in more detail in the next chapter.

Note

There are many other Java packages that we have not touched on, and none of these are unimportantthey are just outside the scope of this book.

A couple more classes worth mentioning are org.springframework.scheduling.quartz. CronTriggerBean and org.springframework.mail.javamail.JavaMailSenderImpl. We will use these in Chapter 10, "Beyond the Basics," to satisfy the automatic email sending requirements we defined in Chapter 2, "The Sample Application: An Online Timesheet System." Furthermore, we will use classes found in the org.springframework.mock.web package to help us unit test our code using mocked web objects. (For general information about mock objects, visit mockobjects.commockobjects.com.)