Whence Spring?
I believe I first started using the Spring Framework in early
2005, and thought it was a wonderful idea and a well-done
implementation. The 90K core was always a big selling point. I then
proceeded to engineer all of my new applications with it, and most are
still running years later.
However, I'm not sure I'll be using Spring again.
Size Matters. The 3.2.2 release of Spring contains 26M of
Jars. Even the core jar is no longer 90K, but now about a meg in
size. However, the actual size isn't as much of a concern as the
complexity added over the years. Spring is now a huge beast that
does much more than just dependency injection, and it is harder
to use just the core without the entire eco-system. Note: I do
like many of Spring's component libraries, like
RestTemplate†† Did you hear the kids over at Apache replaced the old, stand-by, HTTPClient, with the new HTTP Components? .
Complex MVC. After using convention over configuration
frameworks like Grails, using Spring's web application framework
brings back nightmares of typing all day and night just to get a
hello world application running. I have found large applications
written in it difficult to maintain.
Difficult to Test or Difficult to Follow. The Spring
liberation was with its dependency injection as an alternative to
the J2EE bean wiring system, which made it possible to test
everything. Seemed like a great idea until your XML configuration
file grew to a megabyte in size and contained huge amounts of
untestable business logic. The answer from the
Guice Community and eventually Spring 3 was to use
annotations. Improvement? Eh. Let me explain my lack-luster
feeling:
Originally, Class A that needed to call code in Class B would call it
directly with a method call. With DI, you create an interface that A
now depends on, and you can now give A a reference to an instance of B
in two ways:
Autowired. Looks for matching interfaces, and if it only
finds a single option, it automatically connects them. This is
generally discouraged (even those
both sides have advocates).
Explicite. An annotation to A can specify what Class B
reference it should get. At the Java level, there is no
dependency between the classes, and during a unit test, a mock
can easily be passed. This is good, but IDEs are now useless
for following the chain of code without actually starting up a
debugging session.
A better idea that seems to be catching fire is to
wire up the dependencies with some glue code that can be tested
for its interaction. Essentially this takes the concepts in Spring's
original XML file, but uses either Java code or some JVM scripting
language like Groovy or Clojure to stitch the beans together.
One thing that seems important to me is code organization. Frameworks
that support convention over configuration and build tools like
Maven encourage a standard placement of code that is obvious to
maintainers arriving late to the party. Sure, it isn't a panacea
(especially when designing REST applications), Spring MVCs
approach to code location and structure is plain awful.
Better option? Perhaps using the code structure given by using the
Dropwizard project with the lighter-weight Guice DI (see
this project for how these two can be combined keeping in mind
that we can combine Dropwizard and Spring as well).
Tell others about this article:
