Spring was developed as a response to the heavy weight application servers
- These servers imposed a particular programming practise with the mandatory implementation of a pattern.
- By default features such as security and transactions were enabled by default in XML deployment descriptors.
- Lightweight framework that uses IoC (The Hollywood Principle. Don’t call me I will call you). Rather than the programmer managing the creation of objects this is controlled by the Spring Container. Beans are defined in XML files and represented in the code as either ApplicationContext or internally as a BeanFactory. The classes themselves remain as POJO – there is no cohesion to Spring. The objects have their dependencies injected (DI) into them such as their properties.
- Annotations. The use of XML was still tedious. However this can be avoided since Spring 2.0 with the introduction of annotations (since Java 5.0). Classes can be annotated with annotations such as @Component and they will be automatically picked up by the container if we have
<context:component-scan base-package="com.serversense"/> andin the XML configuration file. Member variables can be annotated with @Autowired (Spring specific) or @Inject (JEE6 JSR-299). For a normal desktop application, the basic XML file still needs to be specified and loaded with something like ClassPathXmlApplicationContext. An example can be found here.
- AOP. To add different Concerns onto the application, such as security, transactions or logging, Spring used Aspects. With Aspects, the join points tend to be before,after or around a method calls. The Advice is what to do at the these joint points which is mapped using Pointcuts. Spring also supports more complex join points with the use of Aspectj.
- Template Method Pattern The use of boiler plate code, for example with making JDBC data access calls is avoided in Spring with the extensive use of the Template Method design pattern.