典型的企业应用程序不包含单个对象（或Spring说明中的bean）。 即使是最简单的应用程序，也有几个对象共同合作，展示最终用户看到的一致性应用程序。 下一节将介绍如何从定义一些独立于完全实现的应用程序的bean定义（对象协作实现目标）。

7.4.1 依赖注入

依赖注入（DI）是一个过程，对象定义它们的依赖关系，也就是与它们配合使用的其他对象，只有通过构造函数参数，工厂方法的参数或构造或返回对象实例后设置的属性 从工厂方法。 然后，容器在创建bean时注入这些依赖项。 这个过程基本上是逆向的，因此，控制的控制（IoC）名称本身就是通过使用直接构造类或者服务定位器模式来控制自己的依赖关系的实例化或位置。

使用DI原理，代码更清晰，当对象具有依赖关系时，解耦更有效。 对象不查找其依赖关系，并且不知道依赖关系的位置或类。 因此，您的类变得更容易测试，特别是当依赖关系在接口或抽象基类上时，允许在单元测试中使用存根或模拟实现。

DI存在两种主要的变体：基于构造函数的依赖注入和基于Setter的依赖关系注入。

基于构造函数的依赖注入

基于构造函数的DI通过容器调用具有多个参数的构造函数完成，每个参数表示一个依赖关系。 调用一个具有特定参数的静态工厂方法来构造bean几乎是等效的，这个讨论类似地将参数视为一个构造函数和一个静态的工厂方法。 以下示例显示一个只能使用构造函数注入注入的依赖关系的类。 请注意，这个类没有什么特别之处，它是一个POJO，它不依赖于容器特定的接口，基类或注释。

public class SimpleMovieLister {
    // the SimpleMovieLister has a dependency on a MovieFinder
    private MovieFinder movieFinder;

    // a constructor so that the Spring container can inject a MovieFinder
    public SimpleMovieLister(MovieFinder movieFinder) {
        this.movieFinder = movieFinder;
    }

    // business logic that actually uses the injected MovieFinder is omitted...
}

构造函数解析

使用参数的类型进行构造函数参数解析匹配。 如果在bean定义的构造函数参数中不存在潜在的歧义，那么构造函数参数在bean定义中定义的顺序就是在bean被实例化时将这些参数提供给适当的构造函数的顺序。 考虑下列课程：

没有潜在的模糊性存在，假设Bar和Baz类与继承无关。 因此，以下配置工作正常，您不需要在<constructor-arg />元素中显式指定构造函数参数索引和/或类型。

当引用另一个bean时，类型是已知的，并且可以进行匹配（如前面的例子所示）。 当使用简单的类型，例如<value> true </ value>时，Spring无法确定值的类型，因此无法通过类型匹配，无需帮助。 考虑下列课程：

在上述情况下，如果使用type属性显式指定构造函数参数的类型，则容器可以使用与简单类型匹配的type。 例如：

使用index属性来明确指定构造函数参数的索引。 例如：

除了解决多个简单值的歧义之外，指定索引可以解析构造函数具有两个相同类型参数的歧义。 请注意，索引为0。

您还可以使用构造函数参数名称进行值消除歧义：

请记住，为了使这个工作开箱即用，您的代码必须在启用调试标志的情况下进行编译，以便Spring可以从构造函数中查找参数名称。 如果您无法使用调试标志（或不想）编译代码，则可以使用@ConstructorPropertiesJDK注释来明确命名构造函数参数。 然后样本类必须如下所示：

基于Setter的依赖注入

基于Setter的DI通过在调用无参数构造函数或无参数静态工厂方法来实例化bean之后，通过容器调用bean的setter方法来实现。

以下示例显示一个只能使用纯setter注入进行依赖注入的类。 这个类是常规Java。 它是一个POJO，它不依赖容器特定的接口，基类或注释。

ApplicationContext支持基于构造函数和基于setter的DI，用于其管理的bean。 在一些依赖关系已经通过构造方法注入之后，它也支持基于setter的DI。 您可以以BeanDefinition的形式配置依赖项，该属性与PropertyEditor实例结合使用，以将属性从一种格式转换为另一种格式。 然而，大多数Spring用户不直接使用这些类（即以编程方式），而是使用XML bean定义，注释组件（即，使用@Component，@Controller等注释的类），或者基于Java的@Bean方法@Configuration类。 然后将这些源内部转换为BeanDefinition的实例，并用于加载整个Spring IoC容器实例。

基于构造函数或基于setter的DI？

由于可以混合基于构造函数和基于setter的DI，因此使用构造函数来强制依赖关系和setter方法或可选依赖关系的配置方法是一个>很好的经验法则。 请注意，可以使用setter方法上的@required注释来使属性成为必需的依赖关系。

Spring团队通常主张构造函数注入，因为它可以将应用程序组件实现为不可变对象，并确保所需的依赖关系不为空。 此外，构造函数注入的组件总是以完全初始化的状态返回给客户端（调用）代码。 作为一个附注，大量的构造函数论证是一个坏的代码气味，这意味着该类可能有太多的责任，应该重构以更好地解决问题的正确分离。

Setter注入应主要用于可选依赖关系，可以在类中分配合理的默认值。 否则，必须在代码使用依赖关系的任何地方执行非空检查。 setter注入的一个好处是setter方法使得该类的对象可以在以后重新配置或重新注入。 因此，通过JMX管理MBean是一种引人注目的用例。

使用对特定课程最有意义的DI风格。 有时候，当您处理没有来源的第三方课程时，您可以选择。 例如，如果第三方类不暴露任何>setter方法，那么构造函数注入可能是DI的唯一可用形式。

依赖性解决过程

容器执行如下的bean依赖解析：

• 使用描述所有bean的配置元数据创建和初始化ApplicationContext。 可以通过XML，Java代码或注释指定配置元数据。

• 对于每个bean，如果使用它，而不是正常的构造函数，其依赖性以静态工厂方法的属性，构造函数参数或参数的形式表示。 当bean实际创建时，这些依赖关系被提供给bean。

• 每个属性或构造函数参数是要设置的值的实际定义或引用 容器中另一个bean。

• 作为值的每个属性或构造函数参数都将从其指定的格式转换为该属性或构造函数参数的实际类型。 默认情况下，Spring可以将字符串格式提供的值转换为所有内置类型，如int，long，String，boolean等。

创建容器时，Spring容器会验证每个bean的配置。 但是，bean实际创建之前不会设置bean属性。 单个复制并设置为预实例化（默认）的Bean将在创建容器时创建。 范围在7.5节“Bean范围”中定义。 否则，只有在请求时才创建该bean。 创建bean可能会导致创建bean的图形，因为创建和分配了bean的依赖关系及其依赖关系（等等）。 请注意，这些依赖关系中的解决方案不匹配可能会显示较晚，即首次创建受影响的bean。

循环依赖

如果您主要使用构造函数注入，则可以创建一个无法解决的循环依赖性场景。

例如：Class A通过构造函数注入需要一个类B的实例，B类需要一个通过构造函数注入的A类实例。 如果将类A和B的bean配置为彼此注入，则Spring IoC容器会在运行时检测此循环引用，并抛出一个BeanCurrentlyInCreationException。

一个可能的解决方案是编辑要由setter而不是构造函数配置的某些类的源代码。 或者，避免构造器注入和仅使用设定器注入。 换句话说，虽然不推荐，您可以使用setter注入来配置循环依赖。

与典型的情况（没有循环依赖）不同，bean A和bean B之间的循环依赖关系强制其中一个Bean在被完全初始化之前被注入另一个bean（经典鸡/鸡蛋场景）。

你一般可以信任Spring做正确的事情。它在容器加载时检测到配置问题，例如对不存在的bean和循环依赖项的引用。当bean实际创建时，Spring会尽可能早地设置属性并解析依赖关系。这意味着如果在创建该对象或其依赖关系时出现问题，则在请求对象时可以正确加载的Spring容器可以生成异常。例如，bean由于缺少或无效的属性而抛出异常。某些配置问题的这种潜在的延迟可见性是为什么默认情况下，ApplicationContext实现了单例bean之前的实例化。以实际需要之前创建这些bean的一些前期时间和内存为代价，您可以在创建ApplicationContext时发现配置问题，而不是以后。您仍然可以覆盖此默认行为，以便单例bean将进行延迟初始化，而不是预先实例化。

如果不存在循环依赖关系，当一个或多个协作bean被注入到依赖bean中时，每个协作bean在被注入依赖bean之前被完全配置。 这意味着如果bean A对bean B有依赖关系，则Spring IoC容器在调用bean A的setter方法之前完全配置bean B.换句话说，bean被实例化（如果不是一个预先实例化的单例），它 设置依赖关系，并调用相关的生命周期方法（如配置的init方法或InitializingBean回调方法）。

依赖注入的例子

以下示例使用基于设置器的DI的基于XML的配置元数据。 Spring XML配置文件的一小部分指定了一些bean定义：

在前面的示例中，setter被声明为与XML文件中指定的属性相匹配。以下示例使用基于构造函数的DI：

在bean定义中指定的构造函数参数将被用作构造函数的参数的例子。

现在考虑一个这个例子的变体，而不是使用一个构造函数，Spring被要求调用一个静态工厂方法来返回对象的一个实例：

静态工厂方法的参数通过<constructor-arg />元素提供，与实际使用构造函数完全相同。 工厂方法返回的类的类型不必与包含静态工厂方法的类的类型相同，尽管在此示例中。 将以基本相同的方式使用实例（非静态）工厂方法（除了使用factory-bean属性而不是class属性），因此这里不再讨论细节。

7.4.2 依赖和配置详细

如上一节所述，您可以将bean属性和构造函数参数定义为对其他受管Bean（协作者）的引用，也可以定义为inline。 Spring的基于XML的配置元数据支持其<property />和<constructorarg />元素中的子元素类型。

直接值（基本类型，字符串等）

<property />元素的value属性将一个属性或构造函数参数指定为人类可读的字符串表示形式。 Spring的转换服务用于将这些值从String转换为实际的属性或参数类型。

以下示例使用p-namespace进行更简洁的XML配置。

前面的XML更简洁; 但是，在运行时而不是设计时发现错字，除非您在创建bean定义时使用支持自动属性完成的IDE（如IntelliJ IDEA或Spring Tool Suite（STS））。 强烈建议您使用此类IDE协助。

您还可以将java.util.Properties实例配置为：

Spring容器通过使用JavaBeans PropertyEditor机制将<value />元素内的文本转换为java.util.Properties实例。 这是一个很好的捷径，而且是Spring团队赞成在value属性样式中使用嵌套的<value />元素的几个地方之一。

idref元素

idref元素只是将容器中另一个bean的id（字符串值 - 不是引用）传递给<constructor-arg />或<property />元素的方法。

上述bean定义片段与以下代码片段完全相同（在运行时）：

第一种形式优于第二种形式，因为使用idref标签允许容器在部署时验证引用的命名bean实际存在。 在第二个变体中，不会对传递给clientbean的targetName属性的值执行验证。clientbean实际上被实例化时，才会发现错字（最可能是致命的结果）。 如果clientbean是prototypebean,，则此错误和生成的异常只能在容器部署后才能被发现。

注意

在4.0 beans xsd中，idref元素上的local属性不再受支持，因为它不再提供超过常规bean引用的值。 在升级到4.0模式时，只需将您现有的idref local引用更改为idref bean。

一个常见的地方（至少在Spring 2.0之前的版本中），其中<idref />元素带来价值是在Proxyfactorybean bean定义中配置AOP拦截器。 指定拦截器名称时使用<idref />元素可防止拼写错误。

引用其他bean（协作者）

ref元素是<property />定义元素中的最后一个元素。 在这里，您可以将bean的指定属性的值设置为对由容器管理的另一个bean（协作者）的引用。 引用的bean是其属性将被设置的bean的依赖关系，并且在设置属性之前根据需要初始化它。 （如果协作者是单例bean，则可以由容器初始化它。）所有引用最终都是引用另一个对象。 范围和验证取决于是否通过bean,local,或者parent属性.指定其他对象的id / name。

通过<ref />标签的bean属性指定目标bean是最通用的形式，允许创建对同一容器或父容器中任何bean的引用，而不管它们是否在同一个XML文件中。bean属性的值可能与目标bean的id属性相同，或者与目标bean的name属性中的值之一相同。

通过父属性指定目标bean创建对当前容器的父容器中的bean的引用。 父属性的值可能与目标bean的id属性或目标bean的name属性中的值之一相同，目标bean必须位于当前bean的父容器中。 您使用此bean参考变体主要是在具有容器层次结构时，并且想要使用与父bean具有相同名称的代理将现有bean包装在父容器中。

注意

4.0 bean xsd中不再支持ref元素上的local属性，因为它不再提供超过常规bean引用的值。 在升级到4.0模式时，只需将现有的ref local参考引用改为ref bean。

内部bean

<property />或<constructor-arg />元素中的<bean />元素定义了一个所谓的内部bean。

内部bean定义不需要定义的id或名称; 如果指定，容器不使用这样的值作为标识符。 容器还会忽略创建的scope标志：内部bean始终是匿名的，它们始终使用外部bean创建。 将内部bean注入到除了封闭bean之外的协作bean中，或者独立访问它们是不可能的。

作为一个案例，可以从自定义范围接收销毁回调，例如。 对于包含在单例bean中的请求显示的内部bean：内部bean实例的创建将与其包含的bean绑定，但是破坏回调允许它参与请求范围的生命周期。 这不是一个常见的情况; 内部bean通常只是分享它们的包含bean的范围。

集合

在<list />，<set />，<map />和<props />元素中，您可以分别设置Java集合类型列表，集合，映射和属性的属性和参数。

map的键或值或设置值的值也可以是以下任何元素：

集合的合并

Spring容器还支持集合的合并。 应用程序开发人员可以定义父样式的<map />，<set />或<props />元素，并且具有子样式<props />元素继承并覆盖父集合中的值。 也就是说，子集合的值是合并父集合和子集合的元素的结果，子集合元素覆盖父集合中指定的值。

关于合并的这个部分讨论了父子bean的机制。 不熟悉父和子bean定义的读者可能希望在继续之前阅读相关章节。

以下示例演示集合合并：

请注意，在子bean定义的adminEmails属性的<props />元素上使用merge = true属性。 当子bean由容器解析并实例化时，生成的实例具有一个adminEmails属性集合，该集合包含将该子adminEmails集合与父adminEmails集合合并的结果。

子属性集合的值集继承父项<props />中的所有属性元素，并且支持值的子级值覆盖父集合中的值。

此合并行为类似于<set />集合类型。 在<list />元素的具体情况下，维护与List集合类型相关联的语义，即有序的值集合的概念; 父项的值先于所有子列表的值。 在Map，Set和Properties集合类型的情况下，不存在排序。 因此，对于容器在内部使用的关联的Properties实现类型的集合类型，没有有效的语义。

集合合并的限制

您不能合并不同的集合类型（如Map和List），如果您尝试这样做，则会抛出适当的异常。 合并属性必须在较低的，继承的子定义上指定; 在父集合定义上指定合并属性是多余的，不会导致所需的合并。

强类型集合

通过在Java 5中引入泛型，可以使用强类型集合。 也就是说，可以声明一个Collection类型，使得它只能包含String元素（例如）。 如果您使用Spring将依赖性注入泛型的集合到一个bean中，那么您可以利用Spring的类型转换支持，以便将强类型的Collection实例的元素转换为适当的类型，然后才能添加到 集合。

当foobean的accounts属性准备注入时，有关强类型Map <String，Float>的元素类型的泛型信息可通过反射获得。 因此，Spring的类型转换基础设施将各种值元素识别为Float类型，并将字符串值9.99,244)">2.75和3.99转换为实际的Float类型。

空和空字符串值

Spring将空参数作为空strings处理为属性等。以下基于XML的配置元数据片段将email属性设置为空string值（”“）。

上述示例相当于以下Java代码：