Monday, December 12, 2005

Spring: How to use it without understanding IoC

Subliminally I have been drawn towards looking at Spring. The attraction has reached critical mass and I have finally succumbed. It is not surprising that I should want to look at Spring as I have been constantly drip fed snippets about how magical Spring is in the many disparate Java related articles that I have been browsing through over the last few months.

I've heard much hype about Spring and was hoping to find a breathtaking and spectacular innovation, I didn't find exactly what I expected. Some of the stuff I found looked to be very useful, other bits simply left me bewildered.

Spring at its essence consists of two core parts, BeanFactory and Aspect Oriented Programming (AOP). From what I can tell the most widely used part is the BeanFactory. The only AOP examples I've seen seem to concentrate on how logging could be transparently integrated into Spring applications, I'm certain this is selling AOP short but jumping to Aspect oriented programming is not a paradigm shift I am comfortable about making at the moment.

There is something of a paradigm shift required to understand the principles behind the BeanFactory. Almost every Spring tutorial I have read will start with attempting to explain Inversion of Control (IoC) (aka "The Hollywood Principle" aka "don't call us, we call you" aka "Dependency Injection" [coined by Martin Fowler]). I tend to find that this has the immediate effect of sending me running for the hills but take heart as I have found that I have so far managed to successfully use Spring without actually understanding this particular concept fully. I suppose I am saying don't let the "IoC" explanations prevent you from using Spring!

There is a rumour going about that Spring frees you from writing web specific code, there looks to be some truth to this argument but I have certainly seen plenty of familiar and reassuring web specific stuff inside Spring.

It seems to me that Spring is more of a toolbox rather than a framework. I don't want to get into a semantic argument about what a framework is or isn't but to my mind Spring seems to be less about providing structure and more about providing tools. Spring interfaces well to existing technologies with which you may already be very familiar for example: caching (EHCache), scheduling (Quartz), MVC (Struts, JSF) and O/RM (Hibernate, iBATIS, Toplink). As you might expect from a general toolbox that deals with Beans there are also many other generically useful features that in places bare more than a passing resemblance to Bean and web related offerings from Jakarta Commons and elsewhere.

Spring and Struts

An "optional" component of Spring is its very own web based MVC architecture framework. Instead of writing Controllers, Struts Actions and ActionForms in the Spring MVC architecture everything is a bean. I'm not a MVC purist and I'm sure that there is theoretical merit in this, it is probably closer to true MVC etc.etc. I don't feel comfortable about moving to using Spring MVC as yet although this may change as I learn more about it and see more examples. The thing I like about Struts (and I expect JSF is similar) is the rigid structure it brings to a web applications. Since Spring removes some of these rules I would worry that you could lose some of the beneficial structure. I like the fact that I can hand my Struts application to a colleague with some Struts experience and they pretty much know what to expect without needing to reverse engineer anything or make a careful study of any of my configuration files.

It is also stated that Spring is not prescriptive about what technologies you should use. The Spring community are happy to talk to you even if you are sticking with Struts or JSF or whatever for your MVC implementation. Now you might see what I mean about Spring being more like a toolbox than a framework? There is inherent freedom of choice when using Spring, it provides some very useful tools, used with care it can create fantasically elegant solutions but it does nothing to prevent you from creating bad solutions.

Spring MVC has no apparent Dynabean support, granted real concrete beans aren't difficult to generate if you can find the right options in your IDE. Netbeans carefully hides it getter/setter generation behind a right click on the variable you'd like getter/setters for, click on "Refactor" and then choose to "Encapsulate Fields", obvious really!!!

Spring has a SpringBindingActionForm that looks like it could be used in a DynaActionForm like way but I could find no example documentation beyond the API itself about this class.

What I want to use Spring for

Spring contains some cool looking features but it seems that in several places you are hard pressed to find any example code or tutorials about them. I thought it might be safer to stick with the well documented and hopefully well worn and tested parts of Spring. After having briefly looked at Spring's JDBCTemplate and the other Spring O/RM interfaces to Hibernate, iBATIS, Toplink etc I decided that I wanted to use Spring in my Data Access Object (DAO) layer. I am currently more interested in getting the DAO architecture right (for once) rather than the actual technologies involved. At first glance it seemed to me that Spring would be a very useful and simple DAO implementation technology. I have also seen that Spring contains support for Oracle's perculiar BLOBs and CLOBs implementation which could be very useful for one of my other projects.

Integrating Struts and Spring

Having seen that is quite acceptable to use Struts with Spring I started investigating the various approaches of integrating the two. The first article I read about integrating Struts and Spring, Get a better handle on Struts actions, with Spring, sent me off in what I now consider to be completely the wrong direction.

This article talks about three approaches to incorporating access to Spring beans into Struts Actions. All very impressive but something doesn't feel right to me. I have decided to use Spring in the DAO layer and I feel that unless I start using Spring in some other way it should be confined to the DAO layer therefore I don't need a Spring bean aware Struts Action. After some research I had decided my Struts Action should communicate with my DAO layer via a fa├žade. The DAO implementation may well be using Spring but my Struts Action does not need to know that.

0 comments: