Perhaps the nicest thing about the Spring Framework is the fact that it gives your code an impressive separation of concerns. By following the Spring methodology, you should get this benefit almost for free. The surprising thing about using the Spring Framework philosophy is that your code isn't actually tied to Spring. You just write Plain Old Java Objects (POJOs) and then allow the Spring Framework to bring these objects together in your application. The paradoxical thing about Spring is that it's a framework that doesn't really tie your code to any framework. However, you do have to create some level of Spring linkage—usually in the form of XML files.
At the heart of the Spring approach is the creation of simple POJOs. This is a good thing for a number of reasons:
- It encourages you to concentrate on your core Java classes.
- Spring takes care of combining the relevant objects when your application starts up.
- You basically just "wire up" your application in XML metadata.
- You get to add value by not having to worry about many infrastructure elements.
- Things such as logging, exception, and transaction handling are included as standard.
When you decide to use Spring, you can get on with creating the code that's specific to your problem domain. The Spring design patterns automatically provide you with loose coupling and a deep separation of concerns for your code. One example of the latter is the way you don't have to write reams of JDBC code—Spring provides this for you with its support for data access objects (DAOs). You also can make use of the way Spring supports Hibernate to provide persistence support and advanced transaction management.
Before you can understand how to do these things with Spring, however, you must grasp the basic idea of dependency injection or inversion of control.