My post on DZone about Humble Architects sparked somewhat of a controversy, especially around my disparaing comments regarding Spring and Dependency Injection Frameworks. In this post, I expand on my I stopped using Spring.
I was one of the earliest adopter of Spring in Norway. We developed a large system where we eventually had to start thinking about things like different mechanisms for reuse of XML configuration. Eventually, this evolved into the @Autowire and component-scan which took away the problem with huge configuration files, but in return reduced the ability to reason about the whole source code – instead isolating developers in a very small island in the application.
The applications tended to blossom in complexity as either the culture, the tool, the documentation or something else made developers build unnecessary layer upon unnecessary layer.
Later, I tried to build applications without a Dependency Injection framework, but taking with me the lessons about when to use “new”, when to have a setter or a constructor argument and which types were good to use as dependencies and which created coupling to infrastructure.
So I found that some of the instincts that the DI container had given me made me improve the design, but at the same time, I found that when I removed the container, the solution became smaller (which is good!), easier to navigate and understand and easier to test.
This leaves me with a dilemma. I found that the cost of using the container is very high – it creates a force towards increasing complexity and size and reduced coherence. But at the same time, it taught me some good design skills as well.
In the end, creating a coherent, small system is to me of much higher value than to create one that is decoupled just of the case of decoupling. Coherence and decoupling are opposing forces and I side with coherence.
At the same time, I found that the culture around dependency injection has a very strong preference for reuse. But reuse does introduce coupling. If module A reuses module B, module A and B are coupled. A change in B might affect A for better (a bug fix) or worse (an introduced bug). If the savings from the reuse are high, this is a trade-off worth making. If the savings are low – it is not.
So reuse and decoupling are opposing forces. I find myself siding with decoupling.
When there is a conflict, I value Coherence over decoupling and decoupling over reuse. The culture where Spring is in use seems to have opposite values.
Not just Spring, Hibernate is not necessarily good for most projects.
I’m all for minimalism in design n code.
Completely agree. Spring framework is well intended, but all that configuration makes it more complicated than simply using a simpler and more mentally accessible framework. I dumped Spring MVC in favor of JSF2, which I like just fine. And yes JSF2 does indeed support IoC, which we only use to inject a few things into our 54-page JPA-Hibernate web application.
Whoa, JMS – I hope you don’t mind me saying so, but from Spring to JSF sounds like going from the frying pan into the fire. My personal bad experience is actually more with IoC containers a concept, rather than Spring’s specific implementation (although XML and component-scan are particularly evil).
new is the new new
Good and interesting article. Just for curiosity I would like todo know how you solve some common issues as transactionable methods, which I consider very important. In my opinion using Spring there is a cost we have to pay for automatize some common tasks. But always is necessary break the tend and think jeep in mind the specific domain. I celebrate your point of view.
Hi Leo
With Java 7, transactions can be done like this:
try ( Transaction tx = txManagemer.begin() ) {
// Do something
tx.complete();
}
These lines can of course be moved into Servlet.service in a super class if desired as well. But it’s literally only three lines of code. Hardly worth a whole framework.
well, that’s good…I’m needing a deep update about Java 7 & 8… I would like to run a webapp without Spring container to test the performance and other features… One point for Spring maybe is the rapid development, but as you said, some apps could require strictly performance optimization over development-time. Thanks for comment.
Rapid development with Spring is a lie.
That is: Spring-MVC is a decent framework (as decent as you get anyway). But Spring as a container doesn’t help you go faster.
Here is what I do:
1. Add Jetty as a dependency to my project
2. Create a main class that instantiates org.eclipse.jetty.server.Server and setContext to a new WebAppContext
3. Run this main class in the debugger in Eclipse
(Minor) changes in Java will be reflected automatically in the running code base. No such luck with Spring XML files
“Rapid development with Spring is a lie.”
True!
Awesome! I want to try that!
it’s absolutely true about the debuging time… thanks again for sharing your experiences.
Spring gives you more cleaner and maintainable project in shorter period of time. Yes you are absolutely right when it comes to small/little projects :)
Did you work with Spring Boot?
Now it is really simple. It works like you have mentioned “with a embedded Tomcat and a main method” with addition of convention over configuration and no XML’s.
Spring is mentioned on 3rd line and then one line before the last. This blog post actually is about coupling, which is basic concept going across all programming languages.