Hanumant’s Java Workshop

Turbo Charged Java Development!

Why Spring?

Much has been written about the benefits of the Spring Framework ever since it was released. That Spring framework is light weight, non-invasive, feature rich, etc. is quite well known. But then there are many things that are light weight, non-invasive, and feature rich. What’s so special about Spring? The DI/IoC? Here is my take on it…

In my experience, nearly all non trivial professionally driven projects start out with some fairly common goals, namely – minimize hardcoding, minimize dependency on specific implementation classes, extensible, and easily customizable. These goals are neither unique, nor special. They have been achieved before and are being achieved by many dev teams even now.  Their ubiquity, afterall, is what has driven the invention of various Design Patterns.  Every development team has an architect/designer who has his own view about how to achieve all these goals and assuming that he is well read (w.r.t design patterns), he rolls up some boiler plate code and his own set of conventions that reflects his understanding of the design patterns, which the rest of the team follows. There is nothing fundamentally wrong with this approach. In fact, this is pretty much how applications were being developed for some time now. Long before Spring, Hibernate, or even Struts, I wrote my own framework for developing a discussion forum, resource management, and webbased exam tool on www.jdiscuss.com.

So what’s the problem?

The problem is that a wheel is reinvented everytime a new framework is written. Just imagine what would happen if every car company had its own way of maneuvering  their car. Oh, I can drive a Ford but I guess I need a month long training to drive a Chevy!
This is exactly what happens when new people join the team, or worse, when the architect/designer leaves the team!  I myself find it quite hard and boring to go through framework codebase (who writes documentation?) and understand the whole customized design philosophy. It is a pain to add or update any new feature, not because the framework is poorly written but simply because there is a lot of inertia to learn the nuances of a particular custom framework. For complex applications, there is a huge learning curve and people are not really motivated to learn because this skill is not transferrable to another job instantly. 

This is where we need Spring (and Hibernate/Struts). Spring is basically an implementation, not a mere “specification” or “guideline” but a concrete implementation that can be used right away, of industry approved and time tested good design practices. Not only it gives us a standard way of doing standard things but also a standard way of doing non-standard things. It is a lot easier to swap resources between Spring based projects than between custom framework based projects. Spring is now so widely used accross the industry that a new developer is also quite motivated to learn the system because his resume gets instant recognition 🙂

What about “every application is different”?

Yes, I admit that every application is different and has different needs. However, in my experience, a lot of things that we do are same. We do the same thing – singletons, facades, data access, etc. for every application and Spring provides all the boiler plate code to do that. Further more, Spring has now evolved (as of version 3.0) so much that even for a weird requirement, I am sure there is something available in Spring that does it.  Just check out the reference manual before coding it yourself.

In short, you need Spring. It really is a panacea!

October 3, 2009 Posted by | Java | 3 Comments