深入理解Spring IOC工作原理

　　为什么会出现spring，spring出现解决了什么问题?

　　1.分析普通多层架构存在的问题

　　JSP->Servlet->Service->Dao

层与层之间的依赖很强，属于耦合而且是紧耦合，各层对象的生命周期是由上层控制，下层定义或实现的改动都会影响到上层，需求变更时代码改变多；
通常我们平时都是直接new的，对象生产机制效率较低；

　　2.使用Spring解决紧耦合问题（对象托管）

Spring通过IOC（控制反转）机制和DI（依赖注入）机制将各层之间的（依赖）关系打散。

控制反转：就是由容器(Spring)控制程序之间的（依赖）关系，而非传统实现中，由程序代码直接操控。

依赖注入：组件之间的依赖关系由容器在运行期决定，由容器动态的将某种依赖关系注入到组件之中。

（1）Spring（容器）控制所有对象的生命周期，上层不再控制下层的生命周期，层与层之间实现了完全脱耦，使程序运行起来效率更高，维护起来也方便；

（2）对象的创建方式也由Spring控制，默认是单例，效率比起每次new要高；

（3）IOC就是依赖控制转化，利用JAVA的反射机制，将实例的初始化交给Spring。Spring可以通过配置文件管理实例。

　　3.Spring和简单工厂设计模式有什么不一样？Spring IOC精华所在

　　Spring和简单工厂都实现了控制反转，也就是管理实例的初始化，在需要用该对象的时候，直接从外部申请而获得该对象。下面分析2者的区别

　　简单工厂模型

首先构建工厂类

　　该工厂可以生产苹果和橙子2种对象

然后就是苹果和橙子类和水果接口（为什么需要接口：面向接口来强调的就是我们操纵的都是一些接口，所以我们永远不会依赖于实现）

在测试类中调用

不难发现，其实简单工厂模型和Spring非常相似，都是把对象的创建交给外部实现层解耦，但是当我们深入一层去思考一下问题，当我要在测试类要创建一个西瓜对象的时候，我们首先要加一个西瓜类然后继承水果接口吧，然后呢，第二步就是在工厂类里边加入一段if(是西瓜) else{创建西瓜类} 判断代码是这样吧。来到这里简单工厂模型的弊端就显现出来了，简单来说就是不能做到只是拓展就可以实现想要的，而是要修改代码比如修改工厂类。如果我们添加太多的子类的时候，改动就会很多。

那么Spring是怎么处理的呢？

　　还是上边的例子，水果类和水果类接口就不说了是一样的如图

关键在于工厂类

现在就算我们添加任意多个子类的时候，工厂类都不需要修改。Spring使用反射机制实现的工厂模式可以通过反射取得接口的实例，但是需要传入完整的包和类名。而且用户也无法知道一个接口有多少个可以使用的子类，所以我们通过属性文件的形式配置所需要的子类。初始化的时候能够扫描所有类路径和包名

　　IOC原理小结

IOC中最基本的技术就是反射，通俗来讲就是根据给出的类名来动态地生成对象，这种编程方式可以让对象在生成时才被决定到底是哪一种对象。我们可以把IOC容器的工作模式看做是工厂模式的升华，可以把IOC容器看作是一个工厂，这个工厂里要生产的对象都在配置文件中给出定义，然后利用编程语言提供的反射机制，根据配置文件中给出的类名生成相应的对象。从实现来看，IOC是把以前在工厂方法里写死的对象生成代码，改变为由配置文件来定义，也就是把工厂和对象生成这两者独立分隔开来，目的就是提高拓展性和可维护性。

Spring的基本使用

把需要托管给spring的类注册到配置文件中以bean发布；
在需要用到的地方，以getBean的方式（可提供一个BeanUtil工具类），向spring容器获取对应对象；
若要以依赖注入的方式，先要在配置文件中进行注入，然后在被注入的类中写注入类的setter；、

使用注解（需在XML 配置文件中启动 Spring 的自动扫描功能）

　　Spring 2.5 在 @Repository的基础上增加了功能类似的额外三个注解：@Component、@Service、@Constroller，它们分别用于软件系统的不同层次：

@Component 是一个泛化的概念，仅仅表示一个组件 (Bean) ，可以作用在任何层次。
@Service 通常作用在业务层，但是目前该功能与 @Component 相同。
@Constroller 通常作用在控制层，但是目前该功能与 @Component 相同。