Search This Blog

The evolution of Spring dependency injection techniques

Looking back at the history of Spring
framework you will find out that the number of ways you can implement
dependency injection is growing in every release. If you've been
working with this framework for more than a month you'll probably
find nothing interesting in this retrospective article. Nothing
hopefully except the last example in Scala, language that
accidentally works great with Spring.

There is something disturbing about
this code. First of all there is surprisingly a lot of XML. It is
still less compared to similar EJB 2.1 application (with minor
changes this code runs on Spring 1.2.6 dating back to 2006), but
it just feels wrong. The public setters are even more disturbing –
why are we forced to expose the ability to override object
dependencies at any time and by anyone? By the way I never really
understood why Spring does not allow injecting dependencies directly
to private fields when <property> tag is used since it is
possible with...

Take the first line and you no longer
have to define <property> tags in your XML, only <bean>s.
The framework will pick up standard @Resource annotations. Replace it
with the second line and you don't even have to specify beans in your
XML at all:

Of course you are not impressed! Nihil
novi. Also we still have to live with XML because we have no
control over 3rd party classes (like data source and JdbcTemplate),
hence we can't annotate them. But Spring 3.0 introduced:

I've been already exploring the
@Configuration/@Bean
support, so this time please focus on how we start the application
context. Do you see any reference to the XML file? The
applicationContext.xml descriptor is gone completely:

As you can see Spring came quite a long
road from XML-heavy to XML-free framework. But the most exciting part
is that you can you use whichever style you prefer or even mix them.
You can take legacy Spring application and start using annotations or
switch to XML for god knows what reasons here or there.

One technique I haven't mentioned is
constructor injection. It has some great benefits (see Dependency
Injection with constructors?), like ability to mark
dependencies as final and forbidding to create uninitialized objects:

I would love constructor injection,
however once again I feel a bit disappointed. Each and every object
dependency requires (a) constructor parameter, (b) final field and
(c) assignment operation in constructor. We end up with ten lines of
code that don't do anything yet. This chatty code overcomes all the
advantages. Of course no object should have more than (put your
number here) dependencies – and thanks to constructor injection
you immediately see that the
object has too many – but still I find this code introducing too
much ceremony.

One feature of Scala fits perfectly into Spring framework: each
argument of any Scala object by default creates final field named the
same as this argument. What does this mean in our case? Look at Foo
class translated to Scala:

Almost exactly the same code as we
would have written in Java. With all the advantages: dependencies are
final making our services truly immutable and stateless; dependencies
are private and not exposed to the outside world; literally no extra
code to manage dependencies: just add constructor argument, Scala
will take care of the rest.

To wrap things up – you have a wide
range of possibilities. From XML, through Java code to Scala. The
last approach is actually very tempting as it saves you from all the
boilerplate and allows you to focus on business functionality. The
full source code
is available under my GitHub repository, each step is tagged so you
can compare and choose whichever approach you like the most.

"By the way I never really understood why Spring does not allow injecting dependencies directly to private fields when tag..." That's easy: You can, as long as you're dealing with a "property" as the JavaBean specification defined it. Since the default BeanInfo doesn't, though, you would need to define your own, which essentially nobody does.

Spring, as you noted, extended things past the JavaBeans spec in other places, but they tried hard to follow the published specifications when they could. (Including the @Resource method that you referenced, which went through the JSR process.)

Of course Scala is much nicer than Java, and Spring is flexible enough to work very nicely in both languages. So using both together is a double-win. (Though Scala's got support at the language level that reduces the need that people working in Java have, such as dynamic mixing in of traits.)

Nice post. Indeed Spring framework made development of Java related project lot easier. I have recently using spring security and found that its an excellent library for all common needs which an enterprise of web application needs. It has outofbox support for authentication, authorization, session management and security. documented about LDAP authentication using spring security , you may find useful.

nice blog has been shared by you. before i read this blog i didn't have any knowledge about this but now i got some knowledge. so keep on sharing such kind of an interesting blogs.Devops Training in Bangalore