In next few posts I’m going to introduce Spring framework and a couple buzzwords you can find show up when it comes to Spring Framework.
Overview of Spring Framework
Spring is one of the most popular frameworks for developing web and enterprise applications and it is nearly synonymous with Java development in enterprise circles.
It is not a web framework, or a persistence framework, it’s a framework that integrates all kinds of Java technologies/API’s and makes it possible to use them with simple POJO’s.
What is important to know is that Spring does not reinvent the wheel. It provides a nice and elegant way to use existing technologies (such as EJB, Hibernate, JDO, Toplink, JMS, etc).
Spring is modular, allowing you to use only those parts that you need, without having to bring in the rest. You can use the IoC container, with any web framework on top, but you can also use only the Hibernate integration code or the JDBC abstraction layer. The Spring Framework supports declarative transaction management, remote access to your logic through RMI or web services, and various options for persisting your data. It offers a full-featured MVC framework, and enables you to integrate AOP transparently into your software.
Spring is designed to be non-intrusive, meaning that your domain logic code generally has no dependencies on the framework itself. In your integration layer (such as the data access layer), some dependencies on the data access technology and the Spring libraries will exist. However, it should be easy to isolate these dependencies from the rest of your code base.
Dependency Injection and Inversion of Control
Dependency Injection was originally called Inversion of Control (IoC) because the normal control sequence would be the object finds the objects it depends on by itself and then calls them.
Here, this is reversed: The dependencies are handed to the object when it’s created. It delivers a key advantage: loose coupling. Objects can be added and tested independently of other objects, because they don’t depend on anything other than what you pass them. When using traditional dependencies, to test an object you have to create an environment where all of its dependencies exist and are reachable before you can test it. With DI, it’s possible to test the object in isolation passing it mock objects for the ones you don’t want or need to create.
I am going to explain and show usage of DI in spring in further posts.