With Spring, through dependency injection, our business code does not need to manage the life cycle of associated objects by itself. The business code only needs to follow the process of the business itself, and walk and walk. Wherever you go, you need another object to assist you, just tell Spring, I want an object - so Spring will thoughtfully give you an object. It sounds very simple, and it is not difficult to use, but if you just use it like this, it is free and easy, and it doesn't take a lot of brains. . . However, do you really not care about where Spring gives you the object?
If you want to know more about Spring and not just use it, then you should think about the appeal. Otherwise, you will still read this blog post in vain. . . You can think about it this way: Since Spring is responsible for the creation and management of so many objects in the application, just like Apple is responsible for producing so many mobile phones (objects), there must be a place dedicated to objects. The place where Apple produces mobile phones is called a factory, such as Foxconn, but in software development, the place where Spring develops objects is not called a factory, but a container . Yes, the concept of container in Java is most familiar to you than Tomcat. It is exactly a web container that runs Servlet. If Spring wants to realize the dependency injection function, it cannot do without the object production container - if there is no container Responsible for the creation and management of objects, your program code just asks for objects, and Spring has nowhere to give it to you. In fact, the container is the core of the Spring framework's functionality .The container not only helps us create objects, it is responsible for the management of the entire life cycle of the object - creation, assembly, and destruction.. One of the most commonly heard terms about Spring's container is the IOC container. The so-called IOC is a programming idea called inversion of control. There is a very easy-to-understand summary on the Internet, so I will not explain it randomly. In a word, in my application, I no longer need to worry about object creation and management of dependencies between objects. Let the IOC container do it for me. In other words, I give Spring the control over object creation and management. Container, this is an inversion of control, so the Spring container can be called an IOC container. But here’s something to clarify: It’s not that only Spring’s containers are called IOC containers. There are many frameworks based on IOC containers, which are not unique to Spring.
Okay, I have finally explained the concept of Spring's container, but what's the use? You can’t actually do anything with just a container! Do you think the container is so sci-fi, like the treasure bag in front of Jingle Cat, giving you whatever you want? In fact, there is nothing in the container. It is ourselves who decide what objects to put in the container. It is also we who decide the dependencies between objects. The container only provides us with a space to manage objects. So, how do we put the objects we need the container to manage on our behalf into the container? This involves Spring's application context. What is an application context? You can simply understand that it is a way of putting the objects you need Spring to manage for you into a container. . A sort of. . Forehead. . A container object - yes, the application context is an implementation of the Spring container abstraction ; and our common ApplicationContext is essentially a high-level interface that maintains bean definitions and collaborative relationships between objects.
Um, doesn’t it sound abstract and hard to pronounce? Then read it again. . . Here, we must be clear that the core of Spring is the container, and the container is not unique. The framework itself provides many container implementations, which are roughly divided into two types: one is the uncommon BeanFactory, which is the simplest container. , can only provide basic DI functions; the other is the application context derived from BeanFactory, whose abstract interface is the ApplicationContext we mentioned above, which can provide more enterprise-level services, such as parsing configuration Text information, etc. This is also the most common application scenario for application context instance objects. With the context object, we can register objects that need to be managed by Spring with the container. For the context abstract interface, Spring also provides us with multiple types of container implementations for us to choose from in different application scenarios -
① AnnotationConfigApplicationContext: Load context definitions from one or more java-based configuration classes, suitable for java annotation;
② ClassPathXmlApplicationContext: Load context definitions from one or more xml configuration files under the class path, suitable for xml configuration Method;
③ FileSystemXmlApplicationContext: Load context definition from one or more xml configuration files under the file system, that is to say, load the xml configuration file from the system drive letter;
④ AnnotationConfigWebApplicationContext: Specially prepared for web applications, suitable for annotation mode;
⑤ XmlWebApplicationContext: Load context definition from one or more xml configuration files under the web application, suitable for xml configuration mode.
With the above understanding, the problem will be easy to solve. You only need to base the objects you need the IOC container to manage for you based on xml or java annotations. In short, you need to configure the objects that need to be managed (we all call them beans in Spring) and the collaboration relationships between the beans, and then By loading the application context object into our Spring container, the container can provide your program with the object management services you want. Next, let’s post a simple application context application example:
We first use xml configuration to configure beans and establish collaboration relationships between beans:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.2.xsd">
<bean id="man" class="spring.chapter1.domain.Man">
<constructor-arg ref="qqCar" />
</bean>
<bean id="qqCar" class="spring.chapter1.domain.QQCar"/>
</beans>
Then load the configuration into the IOC container through the application context and let Spring manage the object for us. When we need to use the object, we can get the bean from the container:
public class Test {
public static void main(String[] args) {
//加载项目中的spring配置文件到容器
// ApplicationContext context = new ClassPathXmlApplicationContext("resouces/applicationContext.xml");
//加载系统盘中的配置文件到容器
ApplicationContext context = new FileSystemXmlApplicationContext("E:/Spring/applicationContext.xml");
//从容器中获取对象实例
Man man = context.getBean(Man.class);
man.driveCar();
}
}
In the above test, I placed the configuration file applicationContext.xml in the project and under any system drive letter. I only needed to use the corresponding context object to load the configuration file, and the final result was exactly the same. Of course, more and more java annotations are used in projects now, so the annotation method is essential:
//同xml一样描述bean以及bean之间的依赖关系
@Configuration
public class ManConfig {
@Bean
public Man man() {
return new Man(car());
}
@Bean
public Car car() {
return new QQCar();
}
}
public class Test {
public static void main(String[] args) {
//从java注解的配置中加载配置到容器
ApplicationContext context = new AnnotationConfigApplicationContext(ManConfig.class);
//从容器中获取对象实例
Man man = context.getBean(Man.class);
man.driveCar();
}
}
Since then, the Spring container and application context have been almost explained, and specific skill points will be slowly introduced to you in future blog posts. The blogger's skills are not very deep. There are deficiencies or inaccuracies in the blog post. I welcome the corrections from the great gods and immortals. I would be very grateful.