Hacker News Reader

Comment by ExpiredLink | Hacker News Reader

> Spring brings a lot of functionality to the table. Likely far too much functionality. Most people are moving away from the monolithic application and moving towards smaller more lightweight frameworks…

It's high time to debunk Spring. In the name of 'Dependency Injection' many Java developers still create complex, monolithic and - first of all - untestable applications with this framework. In fact, Spring adds another layer of complexity on top of Java EE without real benefit. It fosters Anti-Patterns like 'Dependency Injection' that give you the illusion of modularity but instead create dependencies within the application ('Dependency Injection' needs to be taken literally).

View on HN

I'm pretty good with Spring and have even given trainings on it and I'd argue that Spring's main problem is that it needs to be seen in the right context: a poor man's DSL for declarative system configuration (it is last 10 years old after all.)

That it creates untestable applications seems like completely nonsensical FUD however since the entire point of Spring is to keep code easily testable. Spring is an almost direct response to the lack of testability of the ServiceLocator anti-pattern.

I'm not saying you can't make untestable code in Spring, but if you do the problem is most likely more with the people than with Spring.

I've done a lot of Spring side work and your first paragraph is the best explanation I've ever read for the framework.

I also agree that if you can't test Spring code you are doing something wrong. I get the frustration with having to create test harnesses for some things, and the SpringJ4Unit stuff oftentimes feels a bit too magical, but I've never seen well written Spring code that wasn't easily testable at the both the class and module functionality layer.

With Spring you can easily test your empty mocked-out shells. Great!

"It fosters Anti-Patterns like 'Dependency Injection' that give you the illusion of modularity but instead create dependencies within the application ('Dependency Injection' needs to be taken literally)."

What? Any system with separated modules is going to have dependencies. At least with DI, classes are written to a interface and different versions easily be swapped in and out.

> Any system with separated modules is going to have dependencies.

Thank you. I thought I was the only doing my nut in over "I've done DI, now I have all the same dependencies" ... adds DIC ... "Now I have all the same dependencies but higher up, and.. oh I need to add logging to 80% of the objects" [Goes to kill myself]

I have OCD about writing beautiful code. The more I try, it seems to real world prevents it from happening.

Eager to learn so if good demo code, resources, books or I'm missing something (obvious or not) I'm all ears.

Try dependency management instead of dependency injection. Layered, modular, hierarchical design instead of 'anything injected into anything'. Divide and conquer instead of DI spaghetti. Testable independent modules instead of mocked-out stubs...

If you want to promote an alternate paradigm you might want to learn to directly argue in favor of your alternative, tather than randomly attacking things that don't fit your personal aesthetics.

I'm also not particularly enamored with the current state of affairs although my pet peeve is more with the lack of adoption of functional reactive programming. That doesn't mean though that I refuse to acknowledge what (or when) Spring was good for or how it fits into the evolution of the industry.

Reply on news.ycombinator.com