3 ms·
I work with Spring and Java EE professionally, prefer Spring wherever I can. Also use Spring for private/side projects (if not plain Java). But I'll talk about
by orless 9y ago
I work with Spring and Java EE professionally, prefer Spring wherever I can. Also use Spring for private/side projects (if not plain Java). But I'll talk about Spring here.
I see two import aspects that Spring provide: first, dependency injection/inversion of control as basis and then a way to 1000+1 things "right".
Dependency injection is important because it provides a healthy way to compose an application from many components or services. It's not exclusive to Spring of course, you can do DI/IoC without Spring (even without any framework), but it's baked into the very nature of Spring.
Next, Spring provides "right" way to do a lot of more-or-less standard things. You have solutions for ORM, REST interfaces, security, batch processing and a thousand more tasks. From my experience, Spring solutions are mostly good or very good, at least much better than I'd design in a limited time frame. This gets me faster to the working solution.
I also don't thing that Spring brings that much of a complexity overhead. Once you got past the first threshold (like, you can assemble you application from a few components) you're good to go. Ok, you will eventually need to learn concepts of individual Spring components (like ORM or security), but you'd need to learn them anyway.
Eventually you'll need to fight Spring here and there, I won't deny it. This is normally related to the "automagical" stuff like autowiring or autoconfigurations - things which make your work easier in 98% but might make you crazy for the rest 2%.
- baylisscg 9y agoI'd add a few more caveats. - Not all Spring projects seem to receive equal love. They can and do stomp on each other. - Spring's get-going-quickly seems to mostly come from serious design assumptions. Which is fine per se but they are not made clear which is not OK. - Spring is far too automagical. My latest bugbear is it deciding to change defaults depending on what it thinks I want. Bonus points for there being multiple settings that control the same behaviour only one of which can override. You're not using Java anymore you're using Spring.
- springsux 9y ago> I see two import aspects that Spring provide: first, dependency injection/inversion of control as basis and then a way to 1000+1 things "right". DI creates debugging nightmares by moving what used to be compile time checks to runtime. Fowler was wrong.
- mvindahl 9y agoThis is a discussion that I've occasionally tried to raise with colleagues. I usually find myself in a pretty isolated position, but anyway.. My viewpoint is, roughly: 1) DI, as described in the GoF book is a great pattern. You compose objects by passing other objects to its constructor as needed. These are the stored in final fields for the lifetime of the parent object. The pattern gives a lot of flexibility and handles a lot of use cases which it may otherwise be tempting to handle using the inferior concept of inheritance. It's simple, it's typesafe, it's easy to debug. 2) DI, as implemented by virtually any DI framework, is the Devil. Most DI frameworks is little more than a big dictionary mapping interface types (or magic strings) to implementation classes, along with some black-box magic to make it work (and bloat your stacktraces). It saves you the effort of calling constructors explicitly but any gains are lost as soon as you need to debug stuff. It shares a lot of traits with that other big dictionary where you can dump stuff for convenience: the global scope. It also has the same backdraws. But anyway, this is a minority position so there is a large chance that I'm dead wrong and a small chance that history will prove me right.
- orless 9y agoSomehow I don't share your experience. What are the problem with DI and debugging? I had a lot WTF moments with automagical things, but not with pure DI.