IOC 容器

IoC 容器

Spring 容器是 Spring 框架的核心。容器将创建对象，把它们连接在一起，配置它们，并管理他们的整个生命周期从创建到销毁。Spring 容器使用依赖注入（DI）来管理组成一个应用程序的组件。这些对象被称为 Spring Beans.

通过阅读配置元数据提供的指令，容器知道对哪些对象进行实例化，配置和组装。配置元数据可以通过 XML，Java 注释或 Java 代码来表示。
下图是 Spring 如何工作的高级视图。 Spring IoC 容器利用 Java 的 POJO 类和配置元数据来生成完全配置和可执行的系统或应用程序。

IOC 容器具有依赖注入功能的容器，它可以创建对象，IOC 容器负责实例化、定位、配置应用程序中的对象及建立这些对象间的依赖。通常new一个实例，控制权由程序员控制，而”控制反转”是指new实例工作不由程序员来做而是交给Spring容器来做。在Spring中BeanFactory是IOC容器的实际代表者。

Spring 提供了以下两种不同类型的容器。

ApplicationContext 容器包括 BeanFactory 容器的所有功能，所以通常不建议使用BeanFactory。BeanFactory 仍然可以用于轻量级的应用程序，如移动设备或基于 applet 的应用程序，其中它的数据量和速度是显著。

BeanFactory 容器

这是一个最简单的容器，它主要的功能是为依赖注入 （DI） 提供支持，
这个容器接口在 org.springframework.beans.factory.BeanFactory中被定义。

BeanFactory 和相关的接口，比如BeanFactoryAware、DisposableBean、InitializingBean，仍旧保留在 Spring 中，主要目的是向后兼容已经存在的和那些 Spring 整合在一起的第三方框架。

在 Spring 中，有大量对 BeanFactory 接口的实现。其中，最常被使用的是 XmlBeanFactory 类。这个容器从一个 XML 文件中读取配置元数据，由这些元数据来生成一个被配置化的系统或者应用。
在资源宝贵的移动设备或者基于 applet 的应用当中， BeanFactory 会被优先选择。
否则，一般使用的是 ApplicationContext，除非你有更好的理由选择 BeanFactory。

ApplicationContext 容器

ApplicationContext 是 BeanFactory 的子接口，也被称为 Spring 上下文。

ApplicationContext 是 spring 中较高级的容器。和 BeanFactory 类似，它可以加载配置文件中定义的 bean，将所有的 bean 集中在一起，当有请求的时候分配 bean。 另外，它增加了企业所需要的功能，比如，从属性文件中解析文本信息和将事件传递给所指定的监听器。
这个容器在 org.springframework.context.ApplicationContext interface 接口中定义。
ApplicationContext 包含 BeanFactory 所有的功能，一般情况下，相对于 BeanFactory，ApplicationContext 会更加优秀。当然，BeanFactory 仍可以在轻量级应用中使用，比如移动设备或者基于 applet 的应用程序。

最常被使用的 ApplicationContext 接口实现：

• FileSystemXmlApplicationContext：该容器从 XML 文件中加载已被定义的 bean。在这里，你需要提供给构造器 XML 文件的完整路径。
• ClassPathXmlApplicationContext：该容器从 XML 文件中加载已被定义的 bean。在这里，你不需要提供 XML 文件的完整路径，只需正确配置 CLASSPATH 环境变量即可，因为，容器会从 CLASSPATH 中搜索 bean 配置文件。
• WebXmlApplicationContext：该容器会在一个 web 应用程序的范围内加载在 XML 文件中已被定义的 bean。

我们已经在 Spring Hello World Example章节中看到过 ClassPathXmlApplicationContext 容器，并且，在基于 spring 的 web 应用程序这个独立的章节中，我们讨论了很多关于 XmlWebApplicationContext。

Bean 定义

被称作 bean 的对象是构成应用程序的支柱也是由 Spring IoC 容器管理的。bean 是一个被实例化，组装，并通过 Spring IoC 容器所管理的对象。这些 bean 是由用容器提供的配置元数据创建的，

bean 定义包含称为配置元数据的信息，下述容器也需要知道配置元数据：

• 如何创建一个 bean
• bean 的生命周期的详细信息
• bean 的依赖关系

上述所有的配置元数据转换成一组构成每个 bean 定义的下列属性。

Bean 与 Spring 容器的关系
下图表达了Bean 与 Spring 容器之间的关系：

Bean 作用域

在Spring中，那些组成应用程序的主体及由Spring IoC容器所管理的对象，被称之为bean。
简单地讲，bean就是由IoC容器初始化、装配及管理的对象 .

一般来说bean的作用域指得是 创建的bean是单实例还是多实例,
除了俩个还有request, session和global-session.

几种作用域中，request、session作用域仅在基于web的应用中使用（不必关心你所采用的是什么web应用框架），只能用在基于web的Spring ApplicationContext环境。

Singleton

当一个bean的作用域为Singleton，那么Spring IoC容器中只会存在一个共享的bean实例，并且所有对bean的请求，只要id与该bean定义相匹配，则只会返回bean的同一实例。
Singleton是单例类型，就是在创建起容器时就同时自动创建了一个bean的对象，不管你是否使用，他都存在了，每次获取到的对象都是同一个对象。注意，Singleton作用域是Spring中的缺省作用域。
要在XML中将bean定义成singleton，可以这样配置：

 <bean id="ServiceImpl" class="cn.csdn.service.ServiceImpl" scope="singleton">

Prototype

当一个bean的作用域为Prototype，表示一个bean定义对应多个对象实例。
Prototype作用域的bean会导致在每次对该bean请求（将其注入到另一个bean中，或者以程序的方式调用容器的getBean()方法）时都会创建一个新的bean实例。
Prototype是原型类型，它在我们创建容器的时候并没有实例化，而是当我们获取bean的时候才会去创建一个对象，而且我们每次获取到的对象都不是同一个对象。根据经验，对有状态的bean应该使用prototype作用域，而对无状态的bean则应该使用singleton作用域。

在XML中将bean定义成prototype，可以这样配置：

<bean id="account" class="com.foo.DefaultAccount" scope="prototype"/>  
  或者
<bean id="account" class="com.foo.DefaultAccount" singleton="false"/>

Request

当一个bean的作用域为Request，表示在一次HTTP请求中，一个bean定义对应一个实例；
即每个HTTP请求都会有各自的bean实例，它们依据某个bean定义创建而成。

该作用域仅在基于web的Spring ApplicationContext情形下有效。考虑下面bean定义：

 <bean id="loginAction" class=cn.csdn.LoginAction" scope="request"/>

针对每次HTTP请求，Spring容器会根据loginAction bean的定义创建一个全新的LoginAction bean实例，
且该loginAction bean实例仅在当前HTTP request内有效，因此可以根据需要放心的更改所建实例的内部状态，
而其他请求中根据loginAction bean定义创建的实例，将不会看到这些特定于某个请求的状态变化。
当处理请求结束，request作用域的bean实例将被销毁。

Session

当一个bean的作用域为Session，表示在一个HTTP Session中，一个bean定义对应一个实例。
该作用域仅在基于web的Spring ApplicationContext情形下有效。考虑下面bean定义：

<bean id="userPreferences" class="com.foo.UserPreferences" scope="session"/>

针对某个HTTP Session，Spring容器会根据userPreferences bean定义创建一个全新的userPreferences bean实例，且该userPreferences bean仅在当前HTTP Session内有效。
与request作用域一样，可以根据需要放心的更改所创建实例的内部状态，而别的HTTP Session中根据userPreferences创建的实例，将不会看到这些特定于某个HTTP Session的状态变化。
当HTTP Session最终被废弃的时候，在该HTTP Session作用域内的bean也会被废弃掉。

Bean 生命周期

生命周期: 从对象创建到对象销毁的过程

Bean的生命周期
(1)通过构造器创建bean实例(无参数构造)
(2)为bean的属性设置值和对其他bean引用(调用set方法)
(3)调用bean的初始化的方法(需要进行配置初始化的方法)
(4)使用bean(对象获取到了)
(5)当容器关闭时候, 调用bean的销毁的方法(需要进行配置销毁的方法)

为了定义安装和拆卸一个 bean，我们只要声明带有**init-method** 和/或**destroy-method** 参数的 。
init-method 属性指定一个方法，在实例化 bean 时，立即调用该方法。
同样，destroy-method 指定一个方法，只有从容器中移除 bean 之后，才能调用该方法。

xml中配置

<bean id="orders" class="com.yuanzi.bran.Orders" 
      init-method="initMethod" destroy-method="destroyMethod">
      <property name="oname" value="手机"></property>
</bean>

销毁方法需要手动调用

//手动让bean实例销毁
context.close()

Bean 后置处理器

Bean 后置处理器允许在调用初始化方法前后对 Bean 进行额外的处理。
加上这步骤,bean的生命周期变成7步:

(1)通过构造器创建bean实例(无参数构造)
(2)为bean的属性设置值和对其他bean引用(调用set方法)
(3)调用后置处理器的 postProcessBeforeInitialization()
(4)调用bean的初始化的方法(需要进行配置初始化的方法)
(5)调用后置处理器的postProcessAfterInitialization()
(6)使用bean(对象获取到了)
(7)当容器关闭时候, 调用bean的销毁的方法(需要进行配置销毁的方法)

BeanPostProcessor 接口定义回调方法，你可以实现该方法来提供自己的实例化逻辑，依赖解析逻辑等。
也可以在 Spring 容器通过插入一个或多个 BeanPostProcessor 的实现来完成实例化，配置和初始化一个bean之后实现一些自定义逻辑回调方法。

xml配置

<!--配置后置处理器-->
<bean id=myBeanPost" class="com.yuanzi.bean.MyBeanPost"></bean>

Bean 定义继承

bean 定义可以包含很多的配置信息，包括构造函数的参数，属性值，容器的具体信息例如初始化方法，静态工厂方法名，等等。
子 bean 的定义继承父定义的配置数据。子定义可以根据需要重写一些值，或者添加其他值。
Spring Bean 定义的继承与 Java 类的继承无关，但是继承的概念是一样的。你可以定义一个父 bean 的定义作为模板和其他子 bean 就可以从父 bean 中继承所需的配置。
当你使用基于 XML 的配置元数据时，通过使用父属性，指定父 bean 作为该属性的值来表明子 bean 的定义。

普通bean和工厂bean

普通bean: 在配置五年级中定义bean类型就是返回类型
工厂bean: 在配置文件中定义bean类型可以和返回类型不一样

1.创建类, 让类做为工厂bean,实现接口FactoryBean
2.实现接口里面的方法, 在实现的方法中定义返回的bean类型