Spring combat study notes (1): overview

Dependency Injection (DI)

Any meaningful application will consist of two or more classes that cooperate with each other to complete specific business logic. Traditionally, each object is responsible for managing references to the objects it collaborates with (that is, the objects it depends on), which results in highly coupled and hard-to-test code.
Through DI (Dependency Injection), the dependencies of objects will be set by the third-party components in the system that are responsible for coordinating each object when creating objects, and objects do not need to create or manage their dependencies by themselves. This implements IoC (Inversion of Control, inversion of control).

application context

The container is the heart of the Spring framework. The Spring container uses DI to manage the components that make up the application, and it creates associations between components that work together. Spring comes with multiple container implementations, which can be grouped into two types, bean factories and application contexts.
Spring typically loads bean definitions and assembles them through the Application Context. The Spring application context is solely responsible for the creation and assembly of objects. Spring comes with a variety of application context implementations, the main difference between them is only how to load the configuration.

1. AnnotationConfigApplicationContext: Loads the Spring application context from one or more Java-based configuration classes
2. AnnotationConfigWebApplicationContext: Loads the Spring web application context from one or more Java-based configuration classes
3. ClassPathXmlApplicationContext: Load context definitions from one or more XML configuration files on the classpath, and use the application context definition files as class resources
4. FileSystemXmlapplicationcontext: Loads context definitions from one or more XML configuration files under the filesystem
5. XmlWebApplicationContext: Load context definitions from one or more XML configuration files under the web application

Aspect Oriented Programming (AOP)

DI keeps cooperating software components loosely coupled, while aspect-oriented programming allows you to separate out functionality from all over the application into reusable components.
AOP is often defined as a technique that enables software systems to achieve separation of concerns. A system consists of many different components, each responsible for a specific piece of functionality. In addition to implementing their own core functionality, these components often have additional responsibilities. System services such as logging, transaction management, and security are often incorporated into components that have their own core business logic. These system services are often referred to as cross-cutting concerns because they span multiple components of the system. AOP makes these services modular and applies them declaratively to the components they need to affect. The result is that these components will be more cohesive and more business-focused, with no need to understand the complexities of involving system services.

bean life cycle

In traditional Java applications, the bean life cycle is simple. The bean is instantiated using the Java keyword new and the bean is ready to use. Once the bean is no longer in use, it is automatically garbage collected by Java.
In contrast, the life cycle of beans in the Spring container is relatively complex:

1. Spring instantiates beans;
2. Spring injects values ​​and bean references into properties corresponding to the bean;
3. If the bean implements the BeanNameAware interface, Spring passes the bean's ID to the setBeanName() method;
4. If the bean implements the BeanFactoryAware interface, Spring will call the setBeanFactory() method and pass in the BeanFactory container instance;
5. If the bean implements the ApplicationContextAware interface, Spring will call the setApplicationContext() method and pass in the reference of the application context where the bean is located;
6. If beans implement the BeanPostProcessor interface, Spring will call their postProcessBeforeInitialization() method;
7. If beans implement the InitializingBean interface, Spring will call their afterPropertiesSet() method. Similarly, if the bean declares an initialization method with initmethod, this method will also be called;
8. If beans implement the BeanPostProcessor interface, Spring will call their postProcessAfterInitialization() method;
9. At this point, the beans are ready to be used by the application, and they will stay in the application context until the application context is destroyed;
10. If the bean implements the DisposableBean interface, Spring will call its destroy() interface method. Likewise, if the bean declares a destroy method with destroy-method, this method will also be called.