《Spring实战（第4版）》——第2章 装配Bean 2.1Spring配置的可选方案

本节书摘来自异步社区《spring实战（第4版）》一书中的第2章，第2.1节，作者： 【美】craig walls（沃尔斯）著，更多章节内容可以访问云栖社区“异步社区”公众号查看

本章内容：

声明bean

构造器注入和setter方法注入

装配bean

控制bean的创建和销毁

在看电影的时候，你曾经在电影结束后留在位置上继续观看片尾字幕吗？一部电影需要由这么多人齐心协力才能制作出来，这真是有点令人难以置信！除了主要的参与人员——演员、编剧、导演和制片人，还有那些幕后人员——音乐师、特效制作人员和艺术指导，更不用说道具师、录音师、服装师、化妆师、特技演员、广告师、第一助理摄影师、第二助理摄影师、布景师、灯光师和伙食管理员（或许是最重要的人员）了。

现在想象一下，如果这些人彼此之间没有任何交流，你最喜爱的电影会变成什么样子？让我这么说吧，他们都出现在摄影棚中，开始各做各的事情，彼此之间互不合作。如果导演保持沉默不喊“开机”，摄影师就不会开始拍摄。或许这并没什么大不了的，因为女主角还呆在她的保姆车里，而且因为没有雇佣灯光师，一切处于黑暗之中。或许你曾经看过类似这样的电影。但是大多数电影（总之，都还是很优秀的）都是由成千上万的人一起协作来完成的，他们有着共同的目标：制作一部广受欢迎的佳作。

在这方面，一个优秀的软件与之相比并没有太大区别。任何一个成功的应用都是由多个为了实现某一个业务目标而相互协作的组件构成的。这些组件必须彼此了解，并且相互协作来完成工作。例如，在一个在线购物系统中，订单管理组件需要和产品管理组件以及信用卡认证组件协作。这些组件或许还需要与数据访问组件协作，从数据库读取数据以及把数据写入数据库。

但是，正如我们在第1章中所看到的，创建应用对象之间关联关系的传统方法（通过构造器或者查找）通常会导致结构复杂的代码，这些代码很难被复用也很难进行单元测试。如果情况不严重的话，这些对象所做的事情只是超出了它应该做的范围；而最坏的情况则是，这些对象彼此之间高度耦合，难以复用和测试。

在spring中，对象无需自己查找或创建与其所关联的其他对象。相反，容器负责把需要相互协作的对象引用赋予各个对象。例如，一个订单管理组件需要信用卡认证组件，但它不需要自己创建信用卡认证组件。订单管理组件只需要表明自己两手空空，容器就会主动赋予它一个信用卡认证组件。

创建应用对象之间协作关系的行为通常称为装配（wiring），这也是依赖注入（di）的本质。在本章我们将介绍使用spring装配 bean的基础知识。因为di是spring的最基本要素，所以在开发基于spring的应用时，你随时都在使用这些技术。

在spring中装配bean有多种方式。作为本章的开始，我们先花一点时间来介绍一下配置spring容器最常见的三种方法。

如第1章中所述，spring容器负责创建应用程序中的bean并通过di来协调这些对象之间的关系。但是，作为开发人员，你需要告诉spring要创建哪些bean并且如何将其装配在一起。当描述bean如何进行装配时，spring具有非常大的灵活性，它提供了三种主要的装配机制：

在xml中进行显式配置；

在java中进行显式配置；

隐式的bean发现机制和自动装配。

乍看上去，提供三种可选的配置方案会使spring变得复杂。每种配置技术所提供的功能会有一些重叠，所以在特定的场景中，确定哪种技术最为合适就会变得有些困难。但是，不必紧张——在很多场景下，选择哪种方案很大程度上就是个人喜好的问题，你尽可以选择自己最喜欢的方式。

spring有多种可选方案来配置bean，这是非常棒的，但有时候你必须要在其中做出选择。

这方面，并没有唯一的正确答案。你所做出的选择必须要适合你和你的项目。而且，谁说我们只能选择其中的一种方案呢？spring的配置风格是可以互相搭配的，所以你可以选择使用xml装配一些bean，使用spring基于java的配置（javaconfig）来装配另一些bean，而将剩余的bean让spring去自动发现。

即便如此，我的建议是尽可能地使用自动配置的机制。显式配置越少越好。当你必须要显式配置bean的时候（比如，有些源码不是由你来维护的，而当你需要为这些代码配置bean的时候），我推荐使用类型安全并且比xml更加强大的javaconfig。最后，只有当你想要使用便利的xml命名空间，并且在javaconfig中没有同样的实现时，才应该使用xml。

在本章中，我们会详细介绍这三种技术并且在整本书中都会用到它们。现在，我们会尝试一下每种方法，对它们是什么样子的有一个直观的印象。作为spring配置的开始，我们先看一下spring的自动化配置。