Evolution of Dependency Injection
In the past few years, thanks to the popularity gained by Spring and other DI frameworks, DI has gained
wide acceptance among the Java developer communities. At the same time, developers were convinced
that using DI was a best practice in application development, and the benefits of using DI were also well
understood.
Widespread DI practice also influenced the development of the Java Community Process (JCP) led
by Sun Microsystems (acquired by Oracle in 2009). In 2009, "Dependency Injection for Java" become a
formal Java Specification Request (JSR-330), and as you might expect, one of the specification leads was
Rod Johnson--the founder of the Spring Framework.
In Java Enterprise Edition version 6 (referred to as JEE 6), JSR-330 became one of the included
specifications of the entire technology stack. In the meantime, the Enterprise JavaBeans (EJB)
architecture (starting from version 3.0) was also revamped dramatically; it adopted the DI model in
order to ease the development of various Enterprise JavaBeans apps.
Although we leave the full discussion of DI until Chapter 4, it is worth taking a look at the benefits of
using DI rather than a more traditional approach:
Reduced glue code: One of the biggest plus points of DI is its ability to reduce
·
dramatically the amount of code you have to write to glue the different
components of your application together. Often this code is trivial--where
creating a dependency involves simply creating a new instance of an object.
However, the glue code can get quite complex when you need to look up
dependencies in a JNDI repository or when the dependencies cannot be invoked
directly, as is the case with remote resources. In these cases, DI can really simplify
the glue code by providing automatic JNDI lookup and automatic proxying of
remote resources.
Simplified application configuration: By adopting DI, the process of configuring
·
an application was greatly simplified. You can use annotations or XML to
configure those classes that were injectable to other classes. You can use the same
technique to express the dependency requirements to the "injector" for injecting
the appropriate bean instance or property. In addition, DI makes it much simpler
to swap one implementation of a dependency for another. Consider the case
where you have a data access object (DAO) component that performs data
operations against a PostgreSQL database and you want to upgrade to Oracle.
Using DI, you can simply reconfigure the appropriate dependency on your
business objects to use the Oracle implementation rather than the PostgreSQL
one.
The ability to manage common dependencies in a single repository: Using a
·
traditional approach to dependency management of common services, for
example, data source connection, transaction, remote services, etc., you create
instances (or lookup from some factory classes) of your dependencies where they
are needed--within the dependent class. This will cause the dependencies to
spread across the classes in your application, and changing them can prove
problematic. When you use DI, all the information about those common
dependencies is contained in a single repository (with Spring, you have the choice
of storing the information in XML files or Java classes), making the management
of dependencies much simpler and less error prone.
Search WWH :
