The last article we introduced two positions ready Spring source code reading environment, then we will begin to explore the principles behind this famous framework. Spring provides the lowest level of the most basic function is the bean container, which is actually the application IoC thought, before learning to realize the principle of the Spring container, we need to first look at what is IoC, this is the focus of this article.
1. IoC
IoC is a noun in recent years with the rise of lightweight containers (Lightweight Container) gradually being brought a lot of people, it's called the Inversion of Control, Chinese usually translated as inversion of control. Hollywood principle "Do not call us, we will call you." Aptly expresses the "reversal" of meaning, is used to describe the maximum sentence IoC.
So why IoC need? What is the specific meaning of IoC is that? It is in the end what is unique? With these questions let us begin our journey IoC.
In order to better illustrate the concept IoC patterns, we introduce a brief scene: the classic MVC project, Controller General Service relies more to accomplish different business logic, here assumed to be serviceA and serviceB, as shown in the following code:
// 示例代码1 public class ControllerA{ private ServiceA serviceA; private ServiceB serviceB; public void doSomething(){ serviceA.doSomething(); serviceB.doSomething(); } }
In general, we can construct two classes, as shown in the constructor directly:
// Sample Code 2 public ControllerA { serviceA = new new ServiceA (); serviceB = new new ServiceB (); }
If we rely on a class or service, the most simple and effective way is to rely on the corresponding new classes directly in the constructor class. We are dependent on their own initiative to acquire objects!
But think back, we own what used to be a time dependent objects take the initiative to get, whether it's really necessary? We finally have to do, in fact, dependent objects directly call a service provided by it. As long as this is used when the dependent objects, it can be ready, we can regardless of the object of their own or someone else got sent over. If someone can when we need to send over a dependent objects, why struggling to toss themselves?
Actually, IoC is to help us before to avoid the "struggling", and provides a more relaxed concise way. Its reversal, let you in on the reverse from the original hands-on, into the present to enjoy the service. The simplest way, embodied in code, may be as follows:
// 示例代码3 public ControllerA (ServiceAbout ServiceAbout, Serviceb Serviceb) { this .serviceA = ServiceAbout; this .serviceB = Serviceb; }
Typically, the object to be injected (ControllerA) directly dependent on the dependent objects (ServiceA, ServiceB), as is the case of the example code written die 2 in the constructor. However, in IoC scenario, between the two is to deal through a IoC Service Provider, it is injected into all of the objects and dependent objects from the IoC Service Provider unified management. 3 embodied in the exemplary code, by the constructor parameter passing to complete injection (actual injection can also be completed by the setter, annotations, etc.).
If you add new requirements, we only need to add a class that implements ServiceA on it, without re-add a Controller, whereas the previous sample code for 2, we would have to rewrite all the code. This is the IoC benefits!
If you use a word to summarize IoC can give us anything, so I hope it is, IoC is a decoupling between us can help each business object dependencies object binding way!
Inversion of Control (IoC), is reflected in where, I think it can be understood as:
-
If we need an object, from out of our own into a new directly from the IoC container already created;
-
An object depends on other objects from the objects in their new constructor dependency object (sample code shown in FIG. 2) into the object (sample code shown in FIG. 3) to inject a dependency IoC container;
You might ask, can I let IoC container to call the constructor 2 sample code to help me complete the injection ah, ah, Chen classmates, the students behind you to stop it!
2.
Speaking on a basic idea of IoC, in IoC mode, dependent objects need to help injected by IoC container, which is dependency injection (Dependency Injection, referred to as DI). Is injected into the object always want to notify IoC container in some way to provide the appropriate service bar, to sum up here:
- Constructor injection;
- Method setter injection;
- Interface injection;
2.1 Constructor injection
As the name suggests, it is to be injected into the injection construction method by which objects can be declared in the dependent object constructor parameter list, so that the external (usually IoC container) it needs to know what the object dependency, as described above with reference to specific examples of the sample code 3.
Constructor injection is relatively straightforward to enter the ready state after the object has been constructed, it may be used immediately.
2.2 setter method injection
For JavaBean objects, usually via the setXXX to access the corresponding attribute () and getXXX () methods. These setXXX () methods collectively setter method, object properties may be changed by the corresponding setter methods. Therefore, as long as an object is added to its dependence on the corresponding setter methods properties, can be provided to the corresponding dependent object is injected into the subject through the setter method, the following simple example:
// 示例代码1 public class ControllerA { private ServiceAbout ServiceAbout; private Serviceb Serviceb; public void Seta (ServiceAbout ServiceAbout) { this .serviceA = ServiceAbout; } Public void SetB (Serviceb Serviceb) { this .serviceB = Serviceb; } }
2.3 interface injection
With respect to the first two injection method, the interface injection is not so simple. Is injected into the object you want to infuse IoC container dependent objects, it must implement an interface. This interface provides a method for its injection dependent objects. After the final IoC container interface through which to understand what dependent objects should be injected is injected into the subject, the most typical to the number of such BeanNameAware, BeanFactoryAware interfaces, the customer object implements these interfaces, the container will automatically inject their respective resources such as beanName , beanFactory.
2.4 Comparison of three kinds of injection method
-
Constructor injection . The advantage of this approach is the injection, the subject had a ready state after the completion of construction, may be used immediately. Drawback is that, when more dependent objects, the constructor argument list will be longer. When reflected by the object structure, would be more difficult to process parameters of the same type (that can experience the source to the reading later), the maintenance and use of too much trouble. And in Java, the constructor can not be inherited, you can not set a default value. For non-mandatory dependency treatment, it may be necessary to introduce more than one constructor, and the number of parameter changes can also cause inconvenience to maintain.
-
setter method injection . setter methods can be inherited, and have a good IDE support. The disadvantage is that objects can not immediately enter the ready state after construction is completed.
-
Interface injection . From the aspect of using an injection, the interface is a way of injecting advocated now less, is injected into the subject because it forces unnecessary interface implemented with invasive implantation method constructed and setter methods such injection is not required.
In summary, the constructor injection and setter injection method because of its invasive nature is weak, and easy to understand and use, it is now the mainstream of the injection method; and interface injection because invasive strong, is now out of fashion, only to retain the Spring Framework the injection part of the interface, such as interface BeanNameAware.
3. IoC container
Although the business objects can be declared by the respective IOC dependent manner, but in the end still need some role or service will bind to these interdependent objects together, and IoC containers (IoC Service Provider) is the IoC scene for this role .
IoC Service Provider just an abstract concept, it may refer to any IoC bind business objects in the scene together implementations, may be a piece of code, or may be a group of related classes, it may also be more common IoC framework or IoC container implementation, common such as Spring.
Responsibilities IoC container is relatively simple, there are two: build dependencies between business objects of management and business object binding.
-
业务对象的构建管理。在IoC场景中，业务对象无需关心所依赖的对象如何构建如何取得，但这部分工作始终需要完成，所以，IoC容器就承担了这个任务，从而避免这部分逻辑污染业务对象的实现。
-
业务对象间的依赖绑定。对于IoC容器来说，这个职责是最艰巨也是最重要的，这是它的使命所在。IoC容器通过结合之前构建和管理的所有业务对象，以及各个业务对象间可以识别的依赖关系，将这些对象所依赖对象注入绑定，从而保证每个业务对象在使用的时候可以处于就绪状态。
4. 总结
本文主要介绍了IoC(控制反转)和DI(依赖注入)的概念，并探索验证了IoC所带给我们的部分"附加值"。在此基础上介绍了常见IoC容器Spring的基本职责，从而对IoC即IoC容器有了最基本认识。