Spring s Values | Professional Java Development with the Spring Framework

Spring's Values

To make the most effective use of Spring, it's important to understand the motivation behind it. Spring partly owes its success to its being based on a clear vision, and remaining true to that vision as its scope has expanded.

The key Spring values can be summarized as follows:

Spring is a non-invasive framework. This is the key departure from most previous frameworks. Whereas traditional frameworks such as EJB or Apache Avalon force application code to be aware of the framework, implementing framework-specific interfaces or extending framework- specific classes, Spring aims to minimize the dependence of application code on the framework. Thus Spring can configure application objects that don't import Spring APIs; it can even be used to configure many legacy classes that were written without any knowledge of Spring. This has many benefits. For example:
- Application code written as part of a Spring application can be run without Spring or any other container.
- Lock-in to Spring is minimized. For example, you could migrate to another lightweight container, or possibly even reuse application objects in an EJB 3.0 EJB container, which supports a subset of Spring's Dependency Injection capability.
- Migration to future versions of Spring is easier. The less your code depends on the framework, the greater the decoupling between the implementation of your application and that of the framework. Thus the implementation of Spring can change significantly without breaking your code, allowing the framework to be improved while preserving backward compatibility.
  
  Of course in some areas, such as the web framework, it's impossible to avoid application code depending on the framework. But Spring consistently attempts to reach the non-invasive ideal where configuration management is concerned.
Spring provides a consistent programming model, usable in any environment. Many web applications simply don't need to run on expensive, high-end, application servers, but are better off running on a web container such as Tomcat or Jetty. It's also important to remember that not all applications are server-side applications. Spring provides a programming model that insulates application code from environment details such as JNDI, making code less dependent on its runtime context.
Spring aims to promote code reuse. Spring helps to avoid the need to make some important hard decisions up front, like whether your application will ever use JTA or JNDI; Spring abstractions will allow you to deploy your code in a different environment if you ever need to. Thus Spring enables you to defer architectural choices, potentially delivering benefits such as the need to purchase an application server license only when you know exactly what your platform requirements are, following tests of throughput and scalability.
Spring aims to facilitate Object Oriented design in J2EE applications. You might be asking "How can a J2EE application, written in Java — an OO language — not be OO?" In reality, many J2EE applications do not deserve the name of OO applications. Spring aims to remove some of the impediments in place of OO in traditional designs. As one of the reviewers on this book commented, "The code I've seen from my team in the year since we adopted Spring has consistently been better factored, more coherent, loosely coupled and reusable."
Spring aims to facilitate good programming practice, such as programming to interfaces, rather than classes. Use of an IoC container such as Spring greatly reduces the complexity of coding to interfaces, rather than classes, by elegantly concealing the specification of the desired implementation class and satisfying its configuration requirements. Callers using the object through its interface are shielded from this detail, which may change as the application evolves.
Spring promotes pluggability. Spring encourages you to think of application objects as named services. Ideally, the dependencies between such services are expressed in terms of interfaces. Thus you can swap one service for another without impacting the rest of your application. The way in which each service is configured is concealed from the client view of that service.
Spring facilitates the extraction of configuration values from Java code into XML or properties files. While some configuration values may be validly coded in Java, all nontrivial applications need some configuration externalized from Java source code, to allow its management without recompilation or Java coding skills. (For example, if there is a timeout property on a particular object, it should be possible to alter its value without being a Java programmer.) Spring encourages developers to externalize configuration that might otherwise have been inappropriately hard-coded in Java source code. More configurable code is typically more maintainable and reusable.
Spring is designed so that applications using it are as easy as possible to test. As far as possible, application objects will be POJOs, and POJOs are easy to test; dependence on Spring APIs will normally be in the form of interfaces that are easy to stub or mock. Unlike the case of JNDI, for example, stubbing or mocking is easy; unlike the case of Struts, for example, application classes are seldom forced to extend framework classes that themselves have complex dependencies.
Spring is consistent. Both in different runtime environments and different parts of the framework, Spring uses a consistent approach. Once you learn one part of the framework, you'll find that that knowledge can be leveraged in many others.
Spring promotes architectural choice. While Spring provides an architectural backbone, Spring aims to facilitate replaceability of each layer. For example, with a Spring middle tier, you should be able to switch from one O/R mapping framework to another with minimal impact on business logic code, or switch from, say, Struts to Spring MVC or WebWork with no impact on the middle tier.
Spring does not reinvent the wheel. Despite its broad scope, Spring does not introduce its own solution in areas such as O/R mapping where there are already good solutions. Similarly, it does not implement its own logging abstraction, connection pool, distributed transaction coordinator, remoting protocols, or other system services that are already well-served in other products or application servers. However, Spring does make these existing solutions significantly easier to use, and places them in a consistent architectural approach.

We'll examine these values later in this chapter and throughout this book. Many of these values are also followed by other lightweight frameworks. What makes Spring unique is that it provides such a consistent approach to delivering on them, and provides a wide enough range of services to be helpful throughout typical applications.