Spring_IOC容器2.docxVIP

5.4?依赖典型的企业应用不会单一得由一个对象组成（或者说Spring术语中的bean）。即便是最简单的系统也需要多个对象共同协作来展示给终端用户一个条理分明的应用。接下来的这一节内容会阐述如何定义多个独立于应用程序的bean一起协同工作完成目标。5.4.1?依赖注入依赖注入 (DI) 是指对象之间的依赖关系，也就是说，一起协作的其他对象只通过构造器的参数、工厂方法的参数或者由构造函数或者工厂方法创建的对象设置属性。因此容器的工 作就是创建bean并注入那些依赖关系。这个过程实质通过直接使用类的构造函数或者服务定位模式来反转控制bean的实例或者其依赖关系的位置，因此它有 另外一个名字叫控制反转 (IoC)。运用了DI原理代码会更加清晰并且由依赖关系提供对象也将使各层次的松耦合变得更加容易。对象不需要知道其依赖关系，也不需要知道它的位置或者类之间的依赖。因此，你的类会更容易测试，尤其是当依赖关系是在接口或者抽象基本类，DI主要有两种注入方式，即docs.tk/beans.html构造器注入和docs.tk/beans.htmlSetter注入。构造器注入基于构造器注入 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定义中构造器参数的定义顺序就是这些参数的顺序并依次进行匹配。看下面的代码：package x.y;public class Foo { public Foo(Bar bar, Baz baz) { // ... }}上述代码中参数类型定义不存在潜在的歧义，我们假设Bar和Baz之间不存在继承关系。因此，下面代码中在元素constructor-arg/的配置即使没有明确指定构造参数顺序或者类型也会起作用。beans bean id=foo class=x.y.Foo constructor-arg ref=bar/ constructor-arg ref=baz/ /bean bean id=bar class=x.y.Bar/ bean id=baz class=x.y.Baz//beans当另一个bean被引用，它的类型是已知的，并且匹配也没问题（跟前面的例子一样）。当我们使用简单类型，比如valuetrue/value。Spring并不能知道该值的类型，不借助其他帮助Spring将不能通过类型进行匹配。看下面的类：package examples;public class ExampleBean { // Number of years to calculate the Ultimate Answer private int years; // The Answer to Life, the Universe, and Everything private String ultimateAnswer; public ExampleBean(int years, String ultimateAnswer) { this.years = years; this.ultimateAnswer = ultimateAnswer; }}针对上面的场景可以使用type属性来显式指定那些简单类型那个的构造参数类型，比如：bean id=exampleBean class=examples.ExampleBean constructor-arg type=int value=7500000/ constructor-arg type=