Injection type of bean in spring

1. Attribute Injection
That is, by injecting the bean's attribute value or dependent object through the Setxxx () method, attribute injection is the most commonly used injection method in practical application because of the advantages of selectivity and flexibility.
Property injection requires that the bean provide a default constructor parameter and provide a corresponding setter method for the property that needs to be injected. Spring invokes the bean's default constructor parameter to instantiate the Bean object, and then invokes the setter method to inject the property value by reflection.
It should be noted that spring will only check if there is a corresponding setter method in the bean, and there is no requirement for the corresponding attribute variable in the bean, such as in the configuration file
<property Name= The property configuration item for the "brand"/> requires only the Setbrand () method in the corresponding class, but not necessarily the brand member variable in the class.
Note: The JavaBean attribute variable name must meet the "first two letters of a variable or all uppercase, or all lowercase" requirements.
Configuration information:
<bean id= "Car" class= "Com.sample.domain.Car" >
<property name= "brand" ><value> Mercedes </value></property>
<bean>

2. Constructor injection
It ensures that some of the necessary properties are set when the bean is instantiated, and that the bean instance can be used after it is instantiated.
1) If the car object must provide the value of brand and price by type matching, the use of attribute injection can only be guaranteed by the configuration, but not the syntax level, and constructor injection will satisfy this requirement. The premise of using constructor injection is that the bean must provide a constructor with parameters.
Configuration information:
<bean id= "car1" class= "Com.sample.domain.Car" >
<constructor-arg type= "Java.lang.String" >
<value> Mercedes </value>
</constructor-arg>
<constructor-arg type= "Double" >
<value>20000</value>
</constructor-arg>
</bean>
Note: The configuration information is based on the type to match the attributes in the class, regardless of the order.
2) by index matching injection, because of a flaw in the injection of type matching (if the parameter types in the constructor do not match correctly), a method that matches the index is provided, which provides the configuration information:
<bean id= "Car2" class= "Com.sample.domain.Car" >
<constructor-arg index= "0" value= "Mercedes"/>
<constructor-arg index= "1" value= "20000"/>
</bean>
3) combined with type and index synthesis injection, 1) and 2).
Configuration information:
<bean id= "Car3" class= "Com.sample.domain.Car" >
<constructor-arg index= "0" type= "java.lang.String" >
<value> Mercedes </value>
</constructor-arg>
<constructor-arg index= "1" type= "Double" >
<value>20000</value>
</constructor-arg>
</bean>
Note: For potential configuration ambiguity caused by the same number of parameters and different types, the spring container can start normally without giving an error message, it will randomly instantiate the bean with a matching constructor, and the chosen constructor may not be desirable by the user. Therefore, special care must be taken.
4) The matching entry is reflected by its own type. If the type of the bean constructor entry is distinguishable (not the underlying data type and the input parameter types are different), because the Java reflection mechanism can get the type of the constructor input, even if the configuration injected by the constructor does not provide the type and index information, spring can still complete the constructor injection correctly.
Configuration information:
<bean id= "Boss" class= "Com.sample.domain.Boss" >
<constructor-arg>
<value>John</value>
</constructor-arg>
<constructor-arg>
<ref bean= "Car"/>
</constructor-arg>
</bean>
Note: The Spring container can successfully instantiate a bean configured with a constructor injection as a precondition: the object referenced by the Bean constructor must be ready. Due to the limitations of this mechanism, if each of the two beans referenced by each other uses construct injection, and both refer to each other through constructor arguments, a circular dependency problem similar to thread deadlock occurs.