|
How does Spring Work?
The idea is that beans follow the Dependency Injection pattern.
Beans have information on the classes dependent on them. Beans
define their own attributes within bean descriptors and also
define the beans they depend on in the same descriptors. The
Bean does not need to locate and instantiate these classes using
service locators or JNDI calls. The Assembler (Spring Framework
in this case) takes care of finding these classes based on the
information provided in the descriptor and makes them available
to the calling class. The service locator pattern does almost
the same job, so why do we need another pattern to do it. The
class that needs the dependent classes needs to tell the Service
Locator as to which classes are required by it and moreover the
responsibility of finding these classes and invoking them falls
on the calling class. This makes the classes tightly coupled
with each other making them difficult to unit test them
separately. In the case of the Dependency Injection pattern the
responsibility is shifted to the Assembler to load these
classes. The assembler can make changes to the dependent classes
by simply modifying the descriptor file. Martin Flower’s article
in the resources shows the comparison between Dependency
Injection and Service Locator with a good example.
Beans, BeanFactory and Application Context
The basic package in the spring framework is the
org.springframework.beans package. Spring framework uses
JavaBeans and this package provides most of the basic
functionality to manipulate Java beans and provides the basic
infrastructure for the other spring framework classes. This
package also provides the basis for the "Dependency injection"
pattern that Spring is based on.
There are two ways in which clients can use the functionality of
the Spring Framework--the BeanFactory and the
ApplicationContext. The BeanFactory is a generic factory, which
stores the information about all the Spring Beans and allows the
user to instantiate beans and manage them. The BeanFactory
provides programmers with the facilities to implement the basic features of
the Spring Framework. The ApplicationContext builds on top of
the BeanFactory and inherits all the basic features of the
Spring Framework. Apart from the basic features,
ApplicationContext provides additional features like Event
management, internationalization support and resource
management.
The BeanFactory is particularly useful in low memory situations
like in an Applet where having the whole API would be overkill.
It provides the basic spring framework features and does not
bring all the excess baggage that ApplicationContext has.
ApplicationContext helps the user to use Spring in a framework
oriented way while the BeanFactory offers a programmatic
approach.
BeanFactory
A BeanFactory is like a factory class that contains a collection
of beans. The BeanFactory holds BeanDefinitions of multiple
beans within itself and then instantiates the bean whenever
asked for by clients.
XMLBeanFactory is a BeanFactory implementation provided within
the Spring Framework. The XMLBeanFactory can read BeanDefinitions
from a XML file directly. The XMLBeanFactory validates the XML
using a DTD file called beans.dtd and checks for inconsistencies
in the XML.
Bean Class
The Bean, which is stored in the BeanFactory, is the actual
class that would carry the logic for the bean. Spring does not
define any standards on how the bean needs to be structured. Any
J2EE complaint bean structure is acceptable to Spring. Unlike
Struts and other frameworks the beans do not need to implement
any special Spring interfaces to make them work in the Spring
Framework. Depending upon the kind of Inversion required the
bean might have to follow the rules of the corresponding
Inversion Dependency pattern. Spring supports only Constructor
based injection and setter based injection. So a bean that used
constructor-based injection should have to define constructors
accordingly. Spring recommends setter-based injection over
constructor-based injection as multiple constructors can make
the bean huge and unmanageable.
A bean has one or more IDs associated with it. The ID should be
unique within the BeanFactory it is contained in so that the
BeanFactory can look up the bean using the ID. If a bean has
multiple IDs they are defined as aliases for the bean.
The spring framework takes care of how the beans can be created
and sent back to clients. Beans can be deployed as singletons or
as non-singletons. If a bean is defined as a singleton then only
one instance of the bean is created by the BeanFactory and
returned when a request for the bean is made. All subsequent
requests get the same instance which was created first. Non-
singleton beans or Prototype beans can have multiple instances
created. So each time a request is made for a bean to the
BeanFactory a new instance is created and returned. The
BeanFactory cannot do Lifecycle management of a prototype bean,
as a new instance is created for each client who requests
it(Lifecycle management of a bean is discussed in a subsequent
section).
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
