As mentioned above, 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, go, go, go, wherever you go, and need another object to assist, just tell Spring, I want an object - so Spring will give you an object very intimately. It sounds simple, and it's not difficult to use, but if it's just such a use, it's free and easy, and it doesn't take any brains. . . However, you really don't care, where does Spring give you the object?
If you want to know more about Spring, not just use it, then you should think about the appeal issue, otherwise, you should read a shovel in this blog post. . . You can think about it this way: Since Spring is responsible for the creation and management of so many objects in an application, just like Apple has to produce so many mobile phones (objects), there must be a place for objects. The place where Apple produces mobile phones is called a factory, such as Foxconn, but in software development, we don’t call it a factory where Spring engages in objects, but a container. Yes, the concept of a container is the most familiar to you in java. It is a web container that runs servlets. If Spring wants to implement the dependency injection function, it is inseparable from the container produced by the object - if there is no container Responsible for the creation and management of objects, your program code is just calling for objects, and Spring has nowhere to give you. In fact, the container is the core of the implementation of the Spring framework. The container is not only as simple as helping 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 common terms you hear about Spring's container is the IOC container. The so-called IOC is a programming idea called inversion of control. There are very easy-to-understand summaries on the Internet, so I will not elaborate. In a word, I don't need to worry about the dependencies between object creation and management objects in my application. Let the IOC container do it for me. That is to say, I hand over the control of object creation and management to Spring. Container, this is an inversion of control, so the Spring container can be called an IOC container. However, here is a point to clarify: it is not that only Spring containers are called IOC containers. There are many frameworks based on IOC containers, which are not unique to Spring.
Well, I finally explained Spring's container concept, but what's the use? You can't really do anything without a container! Do you think the container is so sci-fi, like the treasure bag in front of Jingle Cat, it will give you whatever you want? In fact, there is nothing in the container. It is we who decide what objects are placed in the container, and we are also the one who determines the dependencies between objects. The container only provides us with a space to manage objects. So, how do we put objects into the container that we need the container to manage? This involves Spring's application context. What is an application context? You can simply understand that achievement is a kind of putting the objects you need Spring to manage for you into the 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 the cooperative relationship between objects. Um, doesn't that sound abstract and tongue-in-cheek? Then you read it again. . . Here, we must make it 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 less commonly used BeanFactory, which is the simplest container , can only provide basic DI functions; another 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., which 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 annotations;
② ClassPathXmlApplicationContext: Load context definitions from one or more xml configuration files under the classpath, suitable for xml configuration;
③ FileSystemXmlApplicationContext: Load the context definition from one or more xml configuration files under the file system, that is to say, load the xml configuration file in the system drive letter;
④ AnnotationConfigWebApplicationContext: specially prepared for web applications, suitable for annotation methods;
⑤ XmlWebApplicationContext: Load the context definition from one or more xml configuration files under the web application, suitable for xml configuration.
With the above understanding, the problem is easy to solve. You only need to base the objects that you need the IOC container to manage for you based on xml or java annotations. In short, you need to configure the objects to be managed (we call them beans in Spring) and the collaboration relationship between beans, and then Using the application context object loaded into our Spring container, the container can provide your program with the object management services you want. Below, or paste a simple application context application example:
We first use xml configuration to configure beans and establish a cooperative relationship between beans:
copy code
<?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, it is ok to get the bean from the container:
Copy code public class Test { public static void main(String[] args) { //Load the spring configuration file in the project to the container // ApplicationContext context = new ClassPathXmlApplicationContext("resouces/applicationContext.xml"); //Load the system disk The configuration file in the container to the container ApplicationContext context = new FileSystemXmlApplicationContext("E:/Spring/applicationContext.xml"); //Get the object instance from the container Man man = context.getBean(Man.class); man.driveCar(); } } Copy code
In the above test, I put the configuration file applicationContext.xml in the project and under any system drive letter. I only need to use the corresponding context object to load the configuration file, and the final result is exactly the same. Of course, more and more Java annotations are used in projects now, so the way of annotation is essential:
Copy code//Describe beans and dependencies between beans like xml @Configuration public class ManConfig { @Bean public Man man() { return new Man(car()); } @Bean public Car car() { return new QQCar(); } }
Copy code public class Test { public static void main(String[] args) { //Load configuration from java annotation configuration to container ApplicationContext context = new AnnotationConfigApplicationContext(ManConfig.class); //Get object instance from container Man man = context.getBean(Man.class); man.driveCar(); } } Since then, the Spring container and application context are almost the same, and the specific skill points will be given to you slowly in future blog posts. superior. The blogger's skills are not deep, and there are inappropriate or inaccurate explanations in the blog post. Welcome to corrections from the great gods and heroes. Chen is very grateful.