Friday, April 03, 2009

Is Spring Useful?

I friend recently asked my take on Spring. I thought others might benefit from my response.

> What's your take on the pros and cons of Spring?

You know me, i always seem to have non-standard opinions on things. I can't help it :) I have been using Spring and IOC for a long time. I actually wrote my own (crappy) dependency injection framework before i knew about spring. I have also used used Pico. And lately Guice.

Regarding spring, I use it a lot (it's in the classpath of most projects i do). This is because there are a number of little gems in there. The jdbc stuff, the reflection/bean-util stuff, etc. But, on the whole, i think the *core* of what Spring does is useless (for me). Here is what i have learned that led me to this conclusion:

1. I realized that the IOC pattern is a great pattern, but its a *pattern*, more than a framework. You don't need a framework to do ioc. If you really think of it, the core premise of ioc (or dependeny injection as its also called) is this: Don't lookup dependencies from some kind of global scope. Instead, pass them in as parameters. By "global scope" what i really mean is: (registry | jndi | serviceHashMap | global-variable/singleton). If you really think of it, the ioc pattern is just a re-phrasing of what we have always been taught: prefer explicit argument passing over globals.

Also, in good oo design, one should think about things like "object life cycle" and things like: some objects are users of a service (aka object) while other objects (or object) is in charge of creating the service (or object). This stuff needs to be planned out thoughtfully as part of a good oo design.

So my point here is that 80% of the ioc value comes from the ioc pattern (which is really just good oo practices) and not the ioc framework.

2. We learned that "autowire" has issues. The one area where an ioc framework can actually clean up your code is the "autowire" feature. But, the autowire feature, as it turns out, kills the dave fail-fast/fail-nice principle. In fact, the spring docs caution against the autowire feature.

3. You already know I am against random creation of crappy, unneeded "external" DSL's  (i.e. spring's xml file). There are a million reasons for this. The one good thing about java (the strong type checking) you loose. I kind of view the Spring/Java combo as the absolute worst of all worlds. You don't get all of the great benefits of a dynamic language like Ruby. And you don't get the benefits of type safety.

4. For most things that people use Spring for, I can show them cleaner better ways. Things like transactions, hibernate, dev/staging/production config, swappable impls, factories, etc.

So to summarize, Spring has a place in my toolset, but these days, it is more in the role of an apache commons type of thing. The core idea of what spring is, is mostly useless to me. There are very few use-cases that (for me) warrant the use of Spring (in its central role of ioc/aop container). One use-case would be if i needed a transaction layer that worked seamlessly with JTA (i.e. 2 phase commit) and non-jta environments. But i can't imagine needing that. You either need 2-phase commit or you don't.

If I ever decide to take up ioc frameworks again, it will probably be juice.

2 comments:

shodson said...

Dave, your heresy is very thoughtful :) I don't know why JavaEE is the only platform that I've used where the common developer mind share imposes an IOC framework upon itself. There is much to be said for simplicity and productivity.

Brian Maso said...

Spring Core is what you're talking about -- there are lots of other useful Spring pieces (Spring JDBC, etc.)

Having a single, unified way to define factories and injection points I find incredibly useful for larger and smaller projects. Really helps manage things in the test suite, etc.

Spring MVC? Not nearly so important IMHO. Its an MVC framework -- there's dozens of them out there, and I don't hink Spring's version is even the best one. Same argument for Spring Integration and other Spring frameworks for specific component types. Spring's OK, but its not a de facto mistake to use something else.

The horrendous part of Spring is the very old and unbearable XML-based syntax. It needs to GO. I would kill kittens to replace it with a Groovy Spring config DSL, or some other useful script-based thing.