The Spring Framework: Understanding IoC
(Page 1 of 4 )
IoC or Inversion of Control is one of the core features of Spring. It helps in simplifying the implementation of business logic. To use the Spring Framework to its full potential, understanding the IoC container of the framework is essential. Hence, in this discussion, the focus will be on the IoC – the concept as well as the container provided by Spring Framework.
The first section will focus on the concepts of IoC, including its relationship with Dependency Injection. The focus of the second and third sections will be on the steps necessary to use IoC services provided by the Spring Framework. In the last section, an application will be developed that is based on the concepts explained in first section and whose steps are detailed in the second and third sections. That sets the agenda for this discussion.
What is Inversion of Control?
Inversion of Control or IoC is one of the techniques used to wire services or components to an application program. By definition, IoC is “A software design pattern and set of associated programming techniques in which the flow of control of a system is inverted in comparison to the traditional interaction mode.” Simply stated, in IoC, instead of an application calling the framework, it is the framework that calls the components specified by the application.
This approach is similar to the one that Hollywood agents adopt with their clients. It is sometimes known as “Don’t call me, I will call you.” This is why IoC is also known as the Hollywood approach.
However, IoC is a broad and generic term. The aspect of IoC that the Spring Framework uses is "Injection of required resources or dependency at Run-time into the dependent resource," which is also known as Dependency Injection. Hence, the service provided by the IoC container of Spring is Dependency Injection. Therefore, I will be using the terms IoC and Dependency Injection in a lax way.
There are three forms or styles of Dependency Injection. They are:
Constructor Injection
Setter Injection
Interface Injection
Of these, the Spring Framework directly supports the first and second forms whereas the third form is supported indirectly. Between the first and the second, the Spring Framework prefers the use of second rather than the first. Here are the details.
Constructor Injection: In Constructor Injection, an IoC container uses the constructor to inject the dependency. All the dependencies, whether they are simple values or references to other objects, are declared in the constructor. One of the advantages of Constructor Injection is that all the dependencies are declared in one go. This also helps in understanding whether the class depends on too many services.
Setter Injection: This form of Dependency Injection uses Setters, also known as mutators (because they change the value of the corresponding instance variables), to inject the required resources or dependencies. In other words, each of the objects that the class depends upon will have a setter and the IoC container will use the setters to provide the resource at run-time.
The main difference between Constructor Injection and Setter Injection is that in Constructor Injection, the handing over of the dependencies takes place during instantiation of the dependent object, whereas with Setter Injection, it takes place after the dependent object is instantiated. The Spring Framework favors Setter Injection over Constructor Injection.
Interface Injection: Interface Injection provides the concrete implementations of an interface to the dependent object according to the configuration. The main difference between Interface Injection and the previous two is that in Interface Injection, any of the implementations of the interface can be injected, whereas with the other two, the object of the class specified is injected. Spring does not provide direct support for Interface Injection.
That completes the overview of IoC. Now let us see how to use each of these forms in Spring Framework.
Next: Spring Framework and Forms of IoC: Implementation >>
More Java Articles
More By A.P.Rajshekhar
