Wednesday, March 05, 2008

The Gist of Spring Framework

I've avoided the Spring Framework for some time now. Mostly because I found the XML configuration a little daunting. I could see how nicely the little Hello World examples they gave could work, but the thought of using that on any real-world application seemed impractical. I don't know about you, but I *hate*, wait, let me rephrase that - *HATE* - loads of XML configuration. A few years back it became the trend-du-jour to slap all your configuration into XML files, away from properties files. There was some benefit, since XML files are multi-dimensional in their logical structure.

Anyway, years later, and I hate XML configuration. And Spring seemed to me to be the abomination of all XML configuration tabernacles. I've always kept my eye on it, since everybody and his grandmother seemed to be using it and raving about it. So right now I'm working on a web application that incorporates a few services, including web services, and I figured that since I'd noticed Springs configuration has improved a lot with the use of annotations and autowiring, I'd give Spring a whirl.

I'll probably comment more about my experience with Spring as time goes by, but for now I wanted to make one comment to those fellow Spring newbies out there who might be puzzling with a thing or two. What I call, the 'gist' of Spring. And this is it:

The application context replaces the use of the 'new' keyword.

So, what does that mean? Obviously you still use the 'new' keyword, but the one thing that I couldn't quite get, was when they gave examples of classes that were so wonderfully injected and aspected by Spring, they never showed exactly how to instantiate instances of that class, the one being worked over by Spring. And objects (or 'beans', the word I wish had never entered Java vocabulary) created out of Spring all seemed to be geared toward a Singleton approach. In other words you created an EmailService that all objects used, that needed it of course.

Well this couldn't be further from the truth. Truth be told, you can create any form of object from your Spring application context. And that is the key- the 'gist'. When you need an object, that you want to be setup for you by Spring, get a handle to the ApplicationContext, and use that to create your bean, and it will do all the rest for you. Any class, any object, so long as you've set it up correctly in your application context XML file(s), you're good to go. It's pretty sweet actually.

The next challenge I'm finding is how to get hold of the ApplicationContext. In my case it was fairly simple, in that I can get it from the servlet context for my web application. But you need to then keep a reference to it so you can actually use it in your code. I'm still figuring out the best way to do this. Obviously all the samples use a very simple local application context in the form of some or other test, which also doesn't really help me, but I suppose my frustrations are mostly due to my ignorance. Again though Spring developers, it wouldn't hurt to also show the call in your examples that shows how the actual bean we're after gets created. In other words "ctx.getBean("myBean");". Look at your examples and you'll see. You show the class annotated up to the wazoo, but you don't show how that class is instantiated. Probably because it's trivial to you, but not to us newbies.

6 comments:

Anonymous said...

The people who like Spring Framework have NEVER used it.

Have you ever had problem using JDBC, or writing a servlet, or deploying a webservice?

Well if you have never had a problem with any of the above, using Spring will fix all that.

Anonymous said...

Whatever happened to the KISS principle!! Creating a web app is not rocket science unless you use Spring.

Unknown said...

Agreed. Creating web apps is simple until you use Spring.
I'm in hell, our project is using Spring. It never helps me get anything right. Error messages are obscure, compile time checking is almost non existent.
Trying to find Spring's secret incantations to get things done is destroying my productivity!!!!!

Anonymous said...

I think Maven was invented to manage all the external dependencies that Spring drags with it. Couple the XML configuration of Maven with the numerous XML configuration files for a Spring application and you are up to your eye balls in XML configuration hell.

If you've ever had the pleasure of reading java spaghetti code (yes, you can write spaghetti code in java), this is not far off from reading Spring XML configuration files. Where does the application start??? Can you read the java code for this Spring application and understand how the application works start to finish? I didn't think so... If you prefer writing well written, legible java code to pulling your hair out on Spring XML configuration and studying their over-generalized javadoc APIs, then flee from Spring. I agree with the prior comment about Spring being a dynamically tied together stack of cards. How many application vendors do you see leveraging Spring in their applications? That's telling.

thisendssoon said...
This comment has been removed by the author.
Ron Smith said...

I agree with all the spring haters. I never had a problem building completely functional applications that pretty much any other programmer could pick up and understand until someone got the brilliant idea to introduce Spring.

I don't know about anyone else but my debugger doesn't work on XML files.