Spring IoC Container and Dependency Injection
What is IoC ?
Well, let’s revise what was said in the previous article about Spring Framework’s and IoC pattern’s relation and only then continue diving deeper into details of these topics.
Even though it’s intensively used in “Spring Framework”, an Inversion of Control is not something strictly bound to any language or library. It is a general principle/pattern in software engineering by which the control of objects(creation, destruction …etc), is transferred to a framework. Which means that the act of connecting objects with other objects, or “injecting” objects into other objects, is done by a framework rather than by the objects themselves.
The relation of Spring and IoC pattern is so strong, that “Spring” has one whole component dedicated to it named: “Spring Framework IoC”. And without a doubt it is the nucleus of the framework.
How to use IoC container in Spring Framework?
Ok, i hope you understand that “IoC pattern” is a really cool thing to use in development, for many different reasons like: decoupling, making it easier to switch between different implementations, greater modularity of a program and etc.
But like all patterns, well, it’s just a pattern and without a concrete implementation it’s just an abstract idea.
Basically saying, Spring Framework has our backs by providing “IoC Container”. So the user of the “Spring Framework” will need to “talk” to it as a provider of IoC featues. Thus, it becomes IoCC instead of IoC :).
but how do we use this container ?” you may ask.
Take it in mind that programming has very many straight analogies from the real life. When we say that for some features of the framework you need to use IoC Container, remember that it has the exact same features of a real life containers.
Just like a real life container, empty Spring IoCC is of no usage. So we need to add, store some things/components in it for later usage. The process of filling IoC container with the components you need is called “Configuration” process. The Components which will be stored inside are “Spring beans”. These beans are just simple POJO(Plain Old Java Object)-s that go through this configuration process and are created, assembled (dependencies are
injected), initialized, and managed by the Spring IoC container.
Life of a java object from POJO to Bean
Since in Java, every component you need, most of the time, is an object, the configuration process of Spring IoCC becomes pretty simple.
As you see on the image There are just two steps for configuring your objects to become Spring managed beans.
- You write your class in “Plain Old Java Object” style like you used to( with no args. constructor and setters, getters of all the properties ).
- You add these classes in IoCC by providing some kind of a marker, also known as a configuration metadata. When an application starts, Spring crawls through all the classes in packages and understands that it has to manage the instances of the marked ones, thus adds them in the IoC Container.
Ways of Configuring POJOS and getting Spring beans
There are 3 main ways of configuring/marking POJOS into becoming Spring beans:
- XML Configuration
- Annotation based Configuration
- Java based Configuration
Since these topics are just massive, we’ll just briefly talk about the Grand Father of all the configurations, about the one “from where it all started”, which is “XML Config.”.
XML Configuration Concrete Example
Let’s just replicate the exact steps, for configuring POJOs into Spring beans, specified above, but in a more practical way with some concrete examples.
(FYI we will use UserDao as a class whose instance needs to be managed by Spring IOCC.)
- As already specified we first create Simple POJO. ( Internal fields and behavior is not interesting at the moment since we are only trying to make Spring IOCC instantiate this class and nothing more. )
- Since this is an example of “XML Configuration”, unsurprisingly enough, we create an XML file in the resources folder( Using Maven project ). Please pay attention “bean” tag on the 8th line. all other lines of this XML configuration is just a boiler plate part which can be copy-pasted easily( in fact, that’s exactly what i did :) ). This is the exact marker we were talking about, which helps Spring identify beans to manage.
- Using BeanFactory interface, which is the digital analogy of the container specified earlier:
— We tell Spring to use configuration metadata/markers from our own XML file and instantiate classes that are specified with bean tags in it.
—From now on, whenever we need a UserDao object, instead of creating it manually we can just ask BeanFactory(Container) to give us the bean with provided id.
So this was the basics of IoC Container in Spring FrameWork. Of course there are many important, specific topics left out in the article, but i hope you got the point of this article.
