... Isn't Spring Over?

Posted on May 26, 2004

What is Spring all about?

Spring is commonly described as an Inversion of Control (IOC) or dependency injection container. While I understand what the terms mean, I have the - what would Dave Thomas call it? - novice reaction of.. “So?”

To say Spring does only one thing would be a great injustice. But I have to start in one place, and that’s getting Hibernate and Spring tied together. To do this, a perusal of the documentation and the sample application makes it clear that I’m going to need to work with an ApplicationContext. ApplicationContext is a subclass of BeanFactory, and here’s what the Spring reference manual says that a BeanFactory does:

The BeanFactory provides an advanced configuration mechanism capable of managing beans of any nature, using potentially any kind of storage facility.

Here’s a list of questions I had before my evaluation that were based on this claim, and how Spring ended up.

In other words, clear your mind of what “bean” means in whatever context you are familiar with. “Bean” means any Java class, really. If you’re clever enough, you can use Spring to set up nearly any object you’re interested in. Bean definitions require an implementation class, which is natural enough. One more reason to program to interfaces if you plan on using Spring. Then, you can let it do the dirty work of carrying the right implementation to your classes!

You can describe the methods that need to be called on initialization and destruction of a bean, which is very nice. I can think of a few contexts where that might be useful.

Spring beans can depend on other Spring beans, a concept that will be illustrated in the next Spring post, where you see how to get your hands dirty.

At this point in my evaluation process, Spring does two things. First, it configures SessionFactory objects very nicely. I don’t have to write any ThreadLocal classes, or re-write the same code over and over when I want to use the same code with different input in different contexts (e.g. inside the container, outside the container, local database, remote database). Second, it will manage the Session objects so I don’t have to. I’ll have to keep an eye out to make sure that this is actually working in a way I understand; as a developer, try not to rely on technologies you don’t understand on some level.

Oh, wait, make it four! I get transaction management and second level caching for free. I’m not kidding. Setting up Hibernate’s transaction manager is an extra three lines of XML, and setting up the cache means copying a JAR file. Spring actually complained when I left out the JAR that enabled the caching ability.

These two—er, four— areas make a big win for me. Also, now I’m in a boat with other people who will be working on the finer points for me, so I can focus on getting my work done. Using open source products puts you on a team, for better or worse. I love teams, so for me, it’s better. Spring does many other things, as well, so they’re ready when I am.

I’m still wondering how on Earth Spring is going to handle Session management without knowing about SOFIA! The WebApplicationContext seems like where that magic might happen. Spring is set up and working, however, after about three days of looking at it and working on it off and on. If I do need to understand more about ApplicationContexts to get exactly the behavior I’m looking for, that’s quite all right with me. I’ll share whatever I learn here!

Maybe I was too hard on DAO here. The HibernateClinic class which extends Spring’s HibernateDaoSupport looks exactly like a class I’ve already written to provide many of the same features. If I had written to an interface in the first place, it would be trivial to plug in Spring behind the scenes… for that class, anyway!

A question for the future, since no one actually reads this yet.

Inside the sample petclinic HibernateClinic class, this is about as complex as the code gets:

What about something more complicated? Do your most complicated queries belong in the DAO class/usage pattern? DAO seems to only slightly modify CRUD. Where’s the beef? For now, my persistence service is going to extend HibernateDaoSupport, but will include all the complicated queries.