Spring IOC experience-how to rely on injection

Spring Dependency Injection:

• Attribute Injection

Requirements:

• Each bean needs to provide a default constructor.
• Provides a getter and setter method for attributes that need to be injected. (Spring will only check if there is a corresponding setter method in the bean, and if there is a corresponding attribute variable in the bean does not require)

• Constructor injection

Ensure that some of the necessary properties are set at the beginning of the bean instantiation so that it can be used directly after instantiation.

Requirement: The bean must provide a constructor with parameters

Spring Injection parameter types

• Literal value: Inject directly through <value>
• Refer to other Beans

• Collection type Properties-list

The list property can either inject strings through <value> or inject other beans through <ref>

• Collection type Properties-map

Simplified Configuration method

In order to simplify the configuration of XML, more and more XML files have been introduced into a new P-namespace after Spring2.5 in the way of attribute configuration.

For example:

Automatic Assembly (Autowrite)

With spring's bean configuration, you can learn all the bean information, such as how to construct the bean, attribute information, and so on. These spring containers allow you to automatically assemble the beans in the container according to some rules without having to explicitly configure them.

Annotation-based configuration

@Component

@Service

@Repository

@Controller

These four annotations label the class and can then be identified by the spring container as a bean. Different annotations are only for the purpose of clarity and special provisions for the class itself.

Configuring the bean with annotations needs to be configured in Beans.xml:

Annotation-based automatic assembly of beans

Use @qualifier to specify the name of the Bean, which is automatically injected by type when there is no annotation.

As tested, when using annotations configuration, initializing beanfactory requires the Classpathxmlapplicationcontext class to read the configuration file in such a way that it is initialized:

The specific reasons are not yet identified.

Scope of the Bean

• Singleton: Only one shared bean instance exists in the spring IOC container, and the bean exists as a single instance.

Note: The singleton scope is the default scope in spring. To define a bean as singleton in XML, you can configure this: <bean ... scope= "singleton" >

• Prototype: A new bean instance is created each time a bean is called from the container. Based on experience, you should use the prototype scope for stateful beans, and the singleton scope for stateless beans.

• Request: Each HTTP request will have its own bean instance, which is created from a bean definition. The scope is valid only under Webapplicationcontext.

Consider the following bean definition: <bean ... scope= "Request"/>

For each HTTP request, the spring container creates a completely new instance of the Loginaction bean based on the loginaction bean definition, and the loginaction bean instance is only valid within the current HTTP request. As a result, you can safely change the internal state of the built instance as needed, and other requests that are created from an instance of the Loginaction bean definition will not see these state changes specific to a request. When the processing request ends, the bean instance of the request scope is destroyed.

• session: in an HTTP session, a bean definition corresponds to an instance. The scope is valid only under Web-based Webapplicationcontext.

Consider the following bean definition: <bean ... scope= "Session"/>

For an HTTP session,spring container, an entirely new instance of the Userpreferences Bean is created based on the userpreferences bean definition, and the userpreferences Bean is only present in the current HTTP Session is valid. As with the request scope, you can safely change the internal state of the created instance as needed, while other HTTP sessions will not see the state changes that are specific to an HTTP session based on the instances created by Userpreferences. When the HTTP session is eventually discarded, the beans inside the HTTP session scope are discarded.

• Global session: in a global HTTP session, a bean definition corresponds to an instance. Typically, this is only valid when using the Portlet context. This scope is valid only in the case of a web-based spring ApplicationContext.

Consider the following bean definition: <bean ... scope= "globalsession"/>

The global session scope is similar to the standard HTTP session scope, but it only makes sense in portlet-based Web applications. The Portlet specification defines the concept of a global session, which is shared by all the various portlets that make up a portlet Web application. The bean defined in the global session scope is limited to the lifetime of the world Portlet session.

--------------------------------------------------------------------------------------------------------------- -----------------------------

For more great articles, please visit Liuzhao's Blog

Spring IOC experience-how to rely on injection