欢迎使用CSDN-markdown编辑器

Constructor-based or setter-based DI?

　　Since you can mix constructor-based and setter-based DI, it is a good rule of thumb to use constructors for mandatory dependencies and setter methods or configuration　　　　　　methods for optional dependencies. Note that use of the @Required annotation on a setter method can be used to make the property a required dependency.

　　The Spring team generally advocates constructor injection as it enables one to implement application components as immutable objects and to ensure that required　　　　　　　　　dependencies are not null. Furthermore constructor-injected components are always returned to client (calling) code in a fully initialized state. As a side note, a large number 　　of constructor arguments is a bad code smell, implying that the class likely has too many responsibilities and should be refactored to better address proper separation of concerns.

　　Setter injection should primarily only be used for optional dependencies that can be assigned reasonable default values within the class. Otherwise, not-null checks must be 　　performed everywhere the code uses the dependency. One benefit of setter injection is that setter methods make objects of that class amenable to reconfiguration or re-injection 　　　later. Management through JMX MBeans is therefore a compelling use case for setter injection.

Dependency resolution process

　　The container performs bean dependency resolution as follows:

The ApplicationContext is created and initialized with configuration metadata that describes all the beans. Configuration metadata can be specified via XML, Java code, or annotations.For each bean, its dependencies are expressed in the form of properties, constructor arguments, or arguments to the static-factory method if you are using that instead of a normal constructor. These dependencies are provided to the bean, when the bean is actually created.Each property or constructor argument is an actual definition of the value to set, or a reference to another bean in the container.Each property or constructor argument which is a value is converted from its specified format to the actual type of that property or constructor argument. By default Spring can convert a value supplied in string format to all built-in types, such as int, long, String, boolean, etc

　　The Spring container validates the configuration of each bean as the container is created. However, the bean properties themselves are not set until the bean is actually　　　　　created. Beans that are singleton-scoped and set to be pre-instantiated (the default) are created when the container is created. Scopes are defined in Bean scopes. 　　　　Otherwise, the bean is created only when it is requested. Creation of a bean potentially causes a graph of beans to be created, as the bean’s dependencies and its 　　dependencies’ dependencies (and so on) are created and assigned. Note that resolution mismatches among those dependencies may show up late, i.e. on first creation of the 　　affected bean.

　　You can generally trust Spring to do the right thing. It detects configuration problems, such as references to non-existent beans and circular dependencies, at container load-time. 　　　　Spring sets properties and resolves dependencies as late as possible, when the bean is actually created. This means that a Spring container which has loaded correctly can 　　　later generate an exception when you request an object if there is a problem creating that object or one of its dependencies. For example, the bean throws an exception 　　as a result of a missing or invalid property. This potentially delayed visibility of some configuration issues is why ApplicationContext implementations by default pre-　　　　instantiate singleton beans. At the cost of some upfront time and memory to create these beans before they are actually needed, you discover configuration issues when 　　　　　　　the ApplicationContext is created, not later. You 　　can still override this default behavior so that singleton beans will lazy-initialize, rather than be pre-instantiated.

　　If no circular dependencies exist, when one or more collaborating beans are being injected into a dependent bean, each collaborating bean is totallyconfigured prior to being injected 　　　into the dependent bean. This means that if bean A has a dependency on bean B, the Spring IoC container completely configures bean B prior to invoking the setter method on bean 　　A. In other words, the bean is instantiated (if not a pre-instantiated singleton), its dependencies are set, and the relevant lifecycle methods (such as aconfigured init method or 　　　　　　the InitializingBean callback method) are invoked.
1.4.2. Dependencies and configuration in detail

　　As mentioned in the previous section, you can define bean properties and constructor arguments as references to other managed beans (collaborators), or as values defined inline. 　　　Spring’s XML-based configuration metadata supports sub-element types within its and elements for this purpose.

　　The idref element

　　The idref element is simply an error-proof way to pass the id (string value - not a reference) of another bean in the container to a or element.

1
2
3
4
5
6
7

　　The above bean definition snippet is exactly equivalent (at runtime) to the following snippet:

1
2
3
4
5

　　The first form is preferable to the second, because using the idref tag allows the container to validate at deployment time that the referenced, named bean actually　　　exists. In the second variation, no validation is performed on the value that is passed to the targetName property of the client bean. Typos are only discovered (with most likely　　　fatal results) when the client bean is actually instantiated. If the client bean is a prototype bean, this typo and the resulting exception may only be discovered long after the　　　container is deployed.

　　container is deployed跟bean is actually instantiated都是什么时候？

　　A common place (at least in versions earlier than Spring 2.0) where the element brings value is in the configuration of AOP interceptors in a ProxyFactoryBean bean definition. 　　Using elements when you specify the interceptor names prevents you from misspelling an interceptor id.

　　References to other beans (collaborators)

　　The ref element is the final element inside a or definition element. Here you set the value of the specified property of a bean to be a reference to 　　　　another bean (a collaborator) managed by the container. The referenced bean is a dependency of the bean whose property will be set, and it is initialized on demand as　　　needed before the property is set. (If the collaborator is a singleton bean, it may be initialized already by the container.) All references are ultimately a reference to 　　　　　another object. Scoping and validation depend on whether you specify the id/name of the other object through the bean, local, or parent attributes.

　　Specifying the target bean through the bean attribute of the tag is the most general form, and allows creation of a reference to any bean in the same container or parent container, regardless of whether it is in the same XML file. The value of the bean attribute may be the same as the id attribute of the target bean, or as one of the values in the name attribute of the target bean.

　　父容器？