Tech Head: Rather weak spring critique
Article
Understand, I don't like Spring all that much. For a 'lightweight' framework, it's awfully heavy on the stuff you need to ship to have an 'app' (or at least, it seems that way to me). Still, this guy's critiques are just...weak!
Thoughts:
On Configuration
"Setter injection is bad". Yeah, it's bad. It allows you to create objects in an invalid state, and causes all sorts of runtime state checking of what (often) is an immutable or stateless Object. Still, all recent versions of Spring have allowed us to use constructor injection.
"Don't combine application wiring and configuration". Yeah. Use a property configurator and a regular java .properties file.
On Dependency graphs
Every class implements an interface, just to make it easy for Spring. I wholeheartedly agree with this one, but it's a nit. You can just as easily NOT do this.
On Aspect oriented programming
"This isn't healthy in the general case". Correct, it's not. Most logic should be expressed vertically (a typical algorithm or Object-oriented decomposition), not as an aspect. Even the name implies this, because when programming an aspect, you're programming an aspect OF something.
His assertion here is that Spring sucks because it makes AOP easy enough that non-experts can use it. Spring does add AOP to your toolbox, but the ultimate decision for using it responsibly is yours.
On transparency and abstraction
The crux: Spring does so many things for you behind the scenes, when it breaks, you're stuck. Also, you might involve so many remoting calls that you create a monstrously inefficient application.
As others said in the comments, ultimately programming is hard. Gluing together multiple programs/processes across networks is harder.
The one good point he makes here is Spring's flexibility is somewhat illusory--likely , if you make an app that exposes an API via HTTP, you're never going to change an XML file and magically have that app expose that API via RMI. Why? Because there are rarely requirements for such things. One of the first things you decide on when doing a client/server or distributed app is the method(s) you'll use for remoting.
* * *
My summary: Spring is a juggernaut, but it's in a very precarious place. It allows gluing up applications that can run in J2EE environments, but to have that capability, it's a little bit heavy for writing smaller applications (in the Ruby on Rails vein) that do straightforward things. That is, if I have an app with a dozen or so classes, using a couple of open source libraries, I'll probably just tie it together the old fasioned way--a compiled JAR file, shipped with its dependencies.
Of course, if I'm writing a 'small' app, I'm much more likely to use Ruby. But that's another Tech Head entry, altogether :D
Understand, I don't like Spring all that much. For a 'lightweight' framework, it's awfully heavy on the stuff you need to ship to have an 'app' (or at least, it seems that way to me). Still, this guy's critiques are just...weak!
Thoughts:
On Configuration
"Setter injection is bad". Yeah, it's bad. It allows you to create objects in an invalid state, and causes all sorts of runtime state checking of what (often) is an immutable or stateless Object. Still, all recent versions of Spring have allowed us to use constructor injection.
"Don't combine application wiring and configuration". Yeah. Use a property configurator and a regular java .properties file.
On Dependency graphs
Every class implements an interface, just to make it easy for Spring. I wholeheartedly agree with this one, but it's a nit. You can just as easily NOT do this.
On Aspect oriented programming
"This isn't healthy in the general case". Correct, it's not. Most logic should be expressed vertically (a typical algorithm or Object-oriented decomposition), not as an aspect. Even the name implies this, because when programming an aspect, you're programming an aspect OF something.
His assertion here is that Spring sucks because it makes AOP easy enough that non-experts can use it. Spring does add AOP to your toolbox, but the ultimate decision for using it responsibly is yours.
On transparency and abstraction
The crux: Spring does so many things for you behind the scenes, when it breaks, you're stuck. Also, you might involve so many remoting calls that you create a monstrously inefficient application.
As others said in the comments, ultimately programming is hard. Gluing together multiple programs/processes across networks is harder.
The one good point he makes here is Spring's flexibility is somewhat illusory--likely , if you make an app that exposes an API via HTTP, you're never going to change an XML file and magically have that app expose that API via RMI. Why? Because there are rarely requirements for such things. One of the first things you decide on when doing a client/server or distributed app is the method(s) you'll use for remoting.
* * *
My summary: Spring is a juggernaut, but it's in a very precarious place. It allows gluing up applications that can run in J2EE environments, but to have that capability, it's a little bit heavy for writing smaller applications (in the Ruby on Rails vein) that do straightforward things. That is, if I have an app with a dozen or so classes, using a couple of open source libraries, I'll probably just tie it together the old fasioned way--a compiled JAR file, shipped with its dependencies.
Of course, if I'm writing a 'small' app, I'm much more likely to use Ruby. But that's another Tech Head entry, altogether :D
Comments
Post a Comment