Inverting Control or Injecting Dependencies?
The core of the Spring Framework is based on the principle of Inversion of Control (IoC).. IoC is a
technique that externalizes the creation and management of component dependencies. Consider an
example where class Foo depends on an instance of class Bar to perform some kind of processing.
Traditionally, Foo creates an instance of Bar using the new operator or obtains one from some kind of
factory class. Using the IoC approach, an instance of Bar (or a subclass) is provided to Foo at runtime by
some external process. This behavior, the injection of dependencies at runtime, leads to IoC being
renamed by Martin Fowler to the much more descriptive Dependency Injection (DI). The precise nature
of the dependencies managed by DI is discussed in Chapter 4.
Note As you will see in Chapter 4, using the term Dependency Injection when referring to Inversion of Control
is always correct. In the context of Spring, you can use the terms interchangeably, without any loss of meaning.
Spring's DI implementation is based around two core Java concepts: JavaBeans and interfaces.
When you use Spring as the DI provider, you gain the flexibility of defining dependency configuration
within your applications in different ways (e.g., externally in XML files, Spring Java configuration classes,
or Java annotations within your code). JavaBeans (also known as POJOs, for Plain Old Java Objects)
provide a standard mechanism for creating Java resources that are configurable in a number of ways. In
Chapter 4, you will see how Spring uses the JavaBean specification to form the core of its DI
configuration model; in fact, any Spring-managed resource is referred to as a bean. If you are unfamiliar
with JavaBeans, then refer to the quick primer we present at the beginning of Chapter 4.
Interfaces and DI are technologies that are mutually beneficial. We are sure that no one reading this
topic will disagree that designing and coding an application to interfaces makes for a flexible
application, but the complexity of wiring together an application that is designed using interfaces is
quite high and places an additional coding burden on developers. By using DI, you reduce the amount
of code you need to utilize an interface-based design in your application to almost zero. Likewise, by
using interfaces, you can get the most out of DI because your beans can utilize any interface
implementation
to satisfy their dependency.
In the context of DI, Spring acts more like a container than a framework--providing instances of
your application classes with all the dependencies they need--but it does so in a much less intrusive
way. Using Spring for DI relies on nothing more than following the JavaBeans naming conventions (a
requirement that, as you will see in Chapter 5, you can bypass using Spring's method injection support)
within your classes--there are no special classes from which to inherit or proprietary naming schemes to
follow. If anything, the only change you make in an application that uses DI is to expose more properties
on your JavaBeans, thus allowing more dependencies to be injected at runtime.
Note Spring Framework version 3.0 (and newer) has support for Java-based bean metadata in addition to XML
configuration files.
Search WWH :
