The Spring supermarket
The Spring Framework is an application framework for Java, mainly aimed at making Java Enterprise (J2EE) applications easier to write. The Spring Framework combines several techniques, such as Inversion of Control (through Dependency Injection) and Aspect Oriented Programming, with support for popular design patterns and the (other) popular solution frameworks, such as Hibernate, JSF or Struts.
Spring still sparks a discussion for many. Spring is disliked by people for all sorts of reasons, such as referencing Java in XML, its emphasis on using interfaces, or Rod Johnson talking way too academic when he is giving a presentation about Spring. On the other hand, there are lots of developers that think Spring is the best invention since sliced bread, and think using all of Spring in every situation is a guarantee to have a good solution.
Most important though, people compare J2EE to Spring, bringing the debate to a "J2EE vs Spring" level. Unfortunately, this kind of debate is reinforced by developers of Spring, who use the "evil J2EE" concept as a means to market Spring. The J2EE veterans in turn retaliate by telling that Spring is bad and enterprise programming is just hard and no magic framework can change that. This "yes-no" discussion is very unproductive and on the wrong level. Spring is not a replacement for J2EE: it is an application framework which provides a choice whether or not to use some parts of J2EE, but it is built to leverage J2EE, not to replace it.
To me, Spring poses important benefits in four key areas:
- Testing and configuration Spring has an Inversion of Control container, which basically is a big factory for all your service classes, and can be configured with an XML configuration file. Because the configuration details are no longer in the classes, a lot of Java boilerplate code is no longer needed. It also makes it much easier to use service interfaces, because there is no need to write an additional factory. This makes it much easier to test, because services can now be replaced with mock or stub implementations, at any level in the architecture. For instance: you can easily deploy a web application and start to test it, while stubbing a third-party web service that is not yet finished.
- Death to the utils packages Most frameworks have an API which is oriented at the specific piece of infrastructure they provide (such as JNDI or data access). These kinds of API need boilerplate code to handle resource management, error handling or other common scenarios, and this is often developed as an in-house "utils" package. Spring comes with tons of utility classes to support application programming. When using Spring you typically are not writing another "utils" layer, instead you are programming directly with the Spring helper classes. Spring is designed specifically for extending and changing the default behaviour of these helper classes, so you can still get the corner cases specific for your situation if needed.
- An easy to access AOP framework Spring has an AOP framework which is easy to deploy in a project (no precompiler or classloader magic needed). The Spring AOP framework is limited compared to other options (such as AspectJ). It's simple to use though, and good enough for most common AOP tasks, such as transaction handling, error handling, authorization, tracing, profiling, etc.
- A "lightweight" alternative The J2EE framework stack is powerful and aimed at very large and complex enterprise applications. Unfortunately, this makes some of the frameworks (such as JNDI and EJB) less suitable for simpler problems. Spring provides simple alternatives for these situations. The lightweight alternatives also enable isolated test scenarios with a simpler technology stack.
The best thing about Spring is that it is completely modular, so you can just pick what you need and don't need to know about the rest. You don't need lightweight alternatives? Spring has good support for JNDI and EJB, too. Don't want to configure objects in XML? Then don't do that (writing thread-safe configuration code by hand can be harder that it seems though).
Using the Spring framework is like going to the supermarket. You pick what you need. When it's simple, you pick the cheap stuff on sale. When you need to show off, you pick the most expensive product. Some needs are not met by the supermarket though, you still need to go the specialty shop for those, or make it yourself.
References: