First, we come to know the next IOC and DI:
- IOC (Inversion of Control) Inversion of Control: Inversion of Control, is to create objects inside the original code that needs to be implemented, depending on the code container to help reverse to achieve. So we need to create a container, and a description of the need to let the container know the relationship between the object and the object needs to be created. This document describes the most concrete manifestation is configurable.
- DI (Dependency Injection) DI: refers to a subject is passively rely on their own initiative to find class instead, i.e. it depends on the object class is not to find from the container, but the container when the active object is instantiated it dependent classes injection to it.
Think about the following questions:
- How objects and object-relational representation? Can be represented by xml, properties files semantic profile.
- File describes the relationship between objects stored? classpath, filesystem, servletContext and so on.
- With the configuration file, but also you need to parse the configuration file. Different profiles are not the same as the description of an object, such as standard, custom declarative, how unified it? This requires a unified definition of the object inside, all external description must be converted into a unified description of the definition.
- How to parse the different profiles? The need for different configuration file syntax, different parsers.
Next we look at how Spring is done.
1.BeanFactory
Spring Bean created using the factory pattern, this series of Bean plants, namely IOC container, provides a lot of convenience and basic services for the dependencies between developers managed objects. There are many Spring IOC implemented for selection and use of the container which follows the relationship:
BeanFactory as a top-level interface class defines the basic functional specification IOC containers, BeanFactory three subclasses: ListableBeanFactory, HierarchicalBeanFactory and AutowireCapableBeanFactory. The final category is the default implementation DefaultListableBeanFactory, he implements all interfaces.
Why should so many definitions-level interface it? Now description of these interfaces and the source of discovery, where each interface has his use, mainly in order to distinguish the object transfer and conversion process inside Spring during operation, the data of the target access restriction made. For example ListableBeanFactory interface represents Bean is a list of these, HierarchicalBeanFactory Bean indicates that these are inheritance, that is likely to have a parent each Bean Bean. Bean AutowireCapableBeanFactory automatic assembly interface definition rules. These four interfaces work together to define the relationship between the collection Bean, Bean, Bean's behavior.
BeanFactory we look at the source code in the method:
public interface BeanFactory {
// 对FactoryBean的转义定义，因为如果使用bean的名字检索FactoryBean得到的对象是工厂生成的对象，
// 如果需要得到工厂本身，需要转义
String FACTORY_BEAN_PREFIX = "&";
// 根据bean的名字，获取在IOC容器中得到bean实例
Object getBean(String name) throws BeansException;
//根据bean的名字和Class类型来得到bean实例，增加了类型安全验证机制。
<T> T getBean(String name, @Nullable Class<T> requiredType) throws BeansException;
Object getBean(String name, Object... args) throws BeansException;
<T> T getBean(Class<T> requiredType) throws BeansException;
<T> T getBean(Class<T> requiredType, Object... args) throws BeansException;
// 提供对bean的检索，看看是否在IOC容器有这个名字的bean
boolean containsBean(String name);
//根据bean名字得到bean实例，并同时判断这个bean是不是单例
boolean isSingleton(String name) throws NoSuchBeanDefinitionException;
boolean isPrototype(String name) throws NoSuchBeanDefinitionException;
boolean isTypeMatch(String name, ResolvableType typeToMatch) throws NoSuchBeanDefinitionException;
boolean isTypeMatch(String name, @Nullable Class<?> typeToMatch) throws NoSuchBeanDefinitionException;
// 得到bean实例的Class类型
@Nullable
Class<?> getType(String name) throws NoSuchBeanDefinitionException;
// 得到bean的别名，如果根据别名检索，那么其原名也会被检索出来
String[] getAliases(String name);
}For FACTORY_BEAN_PREFIX, here to explain the following: BeanFactory very similar and there is a class called FactoryBean, easily confused from the name, BeanFactory First Factory, which is FactoryBean bean, is a special kind of bean, this particular bean production will another bean, for common bean, can be obtained by the method of BeanFactory getBean this bean, and for FactoryBean, it is obtained by getBean FactoryBean production of bean, rather than FactoryBean itself, if you want to get FactoryBean itself, you can prefixing &, spring will understand, the original is required FactoryBean.
BeanFactory only the fundamental behavior of IOC containers were defined, we do not care how Bean is the definition of how to load.
To know how the plant is to produce objects need to see concrete realization of the IOC container, Spring provides an implementation of a number of IOC container. For example XmlBeanFactory, ClasspathXmlApplicationContext and so on. XmlBeanFactory which is essential for the realization of the IOC container, the IOC container can read the XML file that defines the BeanDefinition (XML description file for the bean). ApplicationContext is a senior IOC containers Spring offers, in addition to its basic functions to provide the IOC container, but also provides users with the following additional services:
- Support information sources, possible internationalization. (MessageSource implement interfaces)
- Access to resources. (ResourcePatternResolver implement interfaces)
- Support Application event. (Achieve ApplicationEventPublisher Interface)
2.BeanDefinition
SpringIOC container management we define a variety of Bean object of their mutual relationship, the object is achieved in a Spring Bean
to BeanDefinition to describe its inheritance system as follows:
Bean resolution process is very complex, very fine function is divided. Bean resolution mainly to resolve the Spring configuration file.
FIG mainly by the resolution process of complete class:
