Monday, November 26, 2007

My (fairy) Story with Spring

Once upon a Time

TSS has recently published an updated version of the article "Introduction to the Spring Framework" by Rod Johnson. It reminded me of my beginnings with Spring.

It was late 2003 when I stumbled across the first version of that article. My first reaction was "yet another framework". The introduction intrigued me however, so I decided to give it a try. The article struck a chord. I was working on a couple of "typical" J2EE projects back then: a Struts web layer and an EJB2 service layer, plus an always-growing amount of custom infrastructure code. We also used a collection of J2EE patterns throughout the different layers. EJB2 was a mess, Struts was expiring and most of the patterns were of dubious benefit. Everyone knows that now. Back then, that was the standard.

Prince Charming

The article was so enlightening. Spring presented a compelling alternative based on simple and sound principles. Its integration and configuration capabilities immediately interested me. Now new technologies could be integrated smoothly while keeping the configuration externalized and centralized. The numerous and homogeneous abstraction layers finished off convincing me to adopt Spring for my next project.

It took some more reading and research to decide on switching to Spring MVC, although I was aware of Struts shortcomings. Moving to a slightly better framework was not enough. However, the smart and pragmatic design in addition to the uniform configuration model tipped the balance in favor of Spring MVC.

So here came the next project. It was a web application. We implemented a simple layered architecture making use of several Spring components right from the start, mainly Spring MVC for the web layer, Hibernate and JDBC templates/callbacks, declarative transaction management and even some Spring AOP. The whole application was managed and wired by the Spring container. The improvement was quite spectacular.

And They Lived Happily ever after

I moved on to other stuff and enjoyed using various technologies of the Spring portfolio throughout my work. My first Spring application continued to live and to evolve until the time came when it was decided to give it a complete revamp by a different team. The new version was planned to run in a Portlet environment as well.

Two things struck me as remarkable after the new version took shape. First, a large portion of the business code was reused. Second, even the web layer, which I usually consider as disposable, was recuperated and transformed to Spring MVC Portlet with reasonable efforts.

I took a moment to muse about my experience with Spring. Retrospectively, I think that beyond the direct benefits, Spring simply enabled me to write good code. Good code is reusable.Good code is uncluttered and free of unnecessary dependencies.

I have a pet peeve though, regarding Spring’s perception by newcomers. By taking care of the tedious details, Spring could obscure how things work on a lower level. It might even be hard for some people to grasp the point of using Spring when they haven’t been confronted with the problems it solves in the first place. It's normal that what's good eludes you when you haven't been through the bad!