Spring框架由来及IOC的基本概念
一、Spring框架概述
Spring框架所倡导的基于pojo（Plain Old Java Object，简单java对象）的轻量级开发理念，就是从实际出发，立足于最基础的pojo。为了能够让这些基础的pojo构建出健壮而强大的应用，Spring框架就好像那包裹地球的大气层一样，为构筑应用的pojo提供了各种服务，进而创造了一套适应用pojo进行轻量级开发的环境。
从广义上讲，不管Spring框架自发布到现在经过了多少次的版本更迭（从1.X到2.0再到2.5），其本质是始终不变的，都是为了提供各种服务，以帮助我们简化基于pojo的Java应用程序开发。Spring框架为pojo提供的各种服务共同组成了Spring的生命之树
组成整个Spring框架的各种服务实现被划分到了多个相互独立却又相互依赖的模块当中。正如我们图中所见到的那样，这些模块组成了Spring生命之树的枝和干，说白了也就是它组成了Spring框架的核心骨架。抓住了这幅骨架，也就抓住了Spring框架的学习主线。
整个Spring框架构建在Core核心模块之上，它是整个框架的基础。在该模块中，Spring为我们提供了一个ioc容器（Ioc Container）实现，用于帮助我们以依赖注入的方式管理对象之间的依赖关系。对Spring的ioc容器的介绍将成为我们此次Spring之旅的第一站。除此之外，Core核心模块中还包括框架内部使用的各种工具类（如果愿意，我们也可以在框架之外使用），比如Spring的基础io工具类等，这些基础工具类我们也会在合适的地方介绍。
为了简化各种JavaEE服务（像JNDI JMS以及JavaMail等）的使用，Srping框架为我们提供了针对这些JavaEE 服务的继承服务。在Spring的帮助下，这些JavaEE服务现在都变得不再繁琐难用。因为相关的JavaEE服务较多，我们将会选择合适的几种介绍Spring框架给予它们支持。随着航空航天技术的发展，我们现在可以从地球上发送飞船去访问其它星球，使用Spring框架构建基于pojo的应用程序如果也需要远程访问或者公开一些服务的话，Spring的Remoting框架将帮助它完成这一使命。Spring的Remoting框架和Spring对其他JavaEE服务的集成将分别在不同的章节中介绍。
以上就是对整个Spring框架的总体介绍。在开始愉快的Spring旅程之前，我想带大家先逛一逛“Spring大观园“，这样大家就会发现即将开始的Spring之旅更加值得期待。
注意：不要将Spring看作是一个ioc容器，也不要只将Spring与AOP挂钩。Spring提供的远比这些东西要多得多。Spring不仅仅是一个简化JavaEE开发的轻量级框架，它更应该是一个简化任何Java应用的开发框架。如果你愿意，甚至可以在Java的三个平台上（J2SE、J2EE、J2ME）应用Spring框架。即使当前的Spring框架还不支持相应平台或者相应场景的应用开发，但是只要你掌握了Spring的理念和方法，同样可以让新的“Spring”在相应的场景中发挥作用。
二、Spring大观园
在1995年Java作为一门计算机语言诞生时，有谁能够想到，短短10多年间，它已经发展成为一个强大的开发平台？对于Spring框架来说，历史又在重演，而且几乎毫无悬念。
Spring大观园中有一颗参天大树，它得以茁壮成长，主要因为它有一个好的根基，那就是Spring框架。在Spring框架的基础上，Spring家族人丁开始兴旺，不断涌现出一个又一个引入注目的家族成员
三、IOC的基本概念
IOC是随着近年来轻量级容器（LightweughtContainer）的兴起而逐渐被很多人提起的一个名词，它的全称为Inversion of Control,中文通常翻译为“控制反转”，它还有一个别名叫做依赖注入（Dependency Injection）。好莱坞原则“Don't call us,we will call you”恰如其分的表达了“反转”的意味，是用来形容IOC最多的一句话。那么，为什么需要IOC？IOC的具体意义是什么？它到底有什么独到之处？让为破门带着这些疑问开始我们的IOC之旅吧。
实际上，IOC就是为了帮助我们避免之前的“大费周章”，而提供了更加轻松简洁的方式。它的反转，就反转在让你从原来的事必躬亲，转变为现在的享受服务。你想啊，原来还得鞍马劳顿，是什么东西都得自己去拿。现在是用什么，让别人直接送过来就成。所以，简单点说，IOC的理念就是，让别人为你服务，下图也就是让IOC Service Provider来为你服务！
通常情况下，被注入对象会直接依赖于被依赖对象。但是，在IOC的场景中，二者之间通过IOC Service Provider 来打交道，所有的被注入对象和依赖对象现在由IOC Service Provider统一管理。被注入对象需要什么，直接跟IOC Service Provider招呼一声，后者就会把相应的被依赖对象注入到被关注对象中，从而达到IOC Service Provider为被注入对象服务的目的。IOC Service Provider在这里就是通常的IOC容器多充当的角色。从被注入对象的角度看，与之前直接寻求依赖对象相比，依赖对象的取得方式发生了反转，控制也从被注入对象转到了IOC Service Provider那里。
其实IOC就这么简单！原来是需要什么东西自己去拿，现在是需要什么东西就让别人送过来。下图形象的说明了使用IOC模式前后的差别。
构造方法注入
顾名思义，构造方法注入，就是被注入对象可以通过在其构造方法中声明依赖对象的参数列表，让外部（通常是IOC容器）知道它需要哪些依赖对象。
构造方法定义
Ioc Service Provider 会检查被注入对象的构造方法，取得它所需要的依赖对象列表，进而为其注入相应的对象。同一个对象是不可能被构造两次的，因此，被注入对象的构造乃至其整个生命周期，应该是由IOC Service Provider来管理的。
构造方法注入方式比较直观，对象被构造完成后，即进入就绪状态，可以马上使用。这就好比你刚进酒吧的门，服务生已经将你喜欢的啤酒摆上了桌面一样。坐下就可马上享受一份清凉与惬意。
setter方法注入
对于JavaBean对象来说，通常会通过setxxx()和getxxx()方法来访问对应属性。这些setxxx()方法统称为setter方法，getxxx()当然就称为getter方法。通过setter方法，可以更改相应的对象属性，通过getter方法，可以获得相应属性的状态。所以，当前对象只要为其依赖对象所对应的属性添加setter方法，就可以通过setter方法将相应的依赖对象设置到被注入对象中。
这样，外界就可以通过调用setNewsListener和setNewPersistener方法为FXNewsProvider对象注入所依赖对象了。
setter方法注入虽不像构造方法注入那样，让对象构造完成后即可使用，但相对说更宽松一些，可以在对象构造完成后再注入。这就好比你可以到酒吧坐下后再决定要点什么。随意性比较强。
接口注入
相对于前两种注入方式来说，接口注入没有那么简单明了。被注入对象如果想要IOC Service Provider为其注入依赖对象，就必须实现某个接口。这和接口提供一个方法，用来为其注入依赖对象。IOC Service Provider最终通过这些接口来了解应该为被注入对象注入什么依赖对象，下图就演示了如何使用接口注入为FXNewsProvider注入依赖对象
接口注入方式最早并且使用最多的是在一个叫做Avaln的项目中，相对于前两种依赖注入方式，接口注入比较死板和繁琐。如果需要注入依赖对象，被注入对象就必须声明和实现另外的接口。
