spring简介

Spring 目前Java EE 领域中比较流行的一个开源框架，它的目的是为了解决企业应用程序开发的复杂性。Spring框架的分层架构允许在不同的层次上选择各种组件，所以Spring可以和Hibernate、Struts以及JSF等框架结合起来。

Spring框架组成

每个模块的功能如下：

核心容器：核心容器提供Spring框架的基本功能。核心容器的主要组件是 BeanFactory，它是工厂模式的实现。BeanFactory 使用控制反转（IOC）模式将应用程序的配置和依赖性规范与实际的应用程序代码分开。

Spring 上下文：Spring 上下文是一个配置文件，向 Spring 框架提供上下文信息。Spring上下文包括企业服务，例如 JNDI、EJB、电子邮件、国际化、校验和调度功能。

Spring AOP：通过配置管理特性，Spring AOP 模块直接将面向方面的编程功能集成到了 Spring 框架中。所以，可以很容易地使 Spring 框架管理的任何对象支持AOP。Spring AOP模块为基于 Spring 的应用程序中的对象提供了事务管理服务。通过使用 Spring AOP，不用依赖 EJB 组件，就可以将声明性事务管理集成到应用程序中。

Spring DAO：JDBC DAO 抽象层提供了有意义的异常层次结构，可用该结构来管理异常处理和不同数据库供应商抛出的错误消息。异常层次结构简化了错误处理，并且极大地降低了需要编写的异常代码数量（例如打开和关闭连接）。Spring DAO 的面向 JDBC 的异常遵从通用的 DAO 异常层次结构。

Spring ORM：Spring 框架插入了若干个 ORM 框架，从而提供了 ORM 的对象关系工具，其中包括 JDO、Hibernate 和 iBatis SQL Map。所有这些都遵从 Spring 的通用事务和 DAO 异常层次结构。

Spring Web 模块：Web 上下文模块建立在应用程序上下文模块之上，为基于 Web 的应用程序提供了上下文。所以，Spring 框架支持与 Jakarta Struts 的集成。Web 模块还简化了处理多部分请求以及将请求参数绑定到域对象的工作。

Spring MVC 框架：MVC 框架是一个全功能的构建 Web 应用程序的 MVC 实现。通过策略接口，MVC 框架变成为高度可配置的，MVC 容纳了大量视图技术，其中包括 JSP、Velocity、Tiles、iText 和 POI。

在Spring中主要用到的模式是Inversion of Control模式和Dependency Inversion 模式，先从 Dependency Inversion 开始，也就是依赖关系的反转。

简单地说，在模块设计时，高层的抽象模块通常是与业务相关的模块，它应该具有重用性，而不依赖于低层的模块，例如如果低层模块原先是磁盘存取模式，而高层模块是个存档备份的需求，如果高层模块直接调用低层模块的方法，则就对低层模块产生了依赖关系。

例如下面这段代码：

#include

....

void save() {

....

saveToFloppy()

}

}

由于save()方法依赖于saveToFloppy()，如果要更换低层的存储模式为USB，则这个方法没有办法重用，必须加以修改才行，低层模式的更改造成了上层模式也必须跟着改变，这不是一个好的设计方式，在设计上希望模式都依赖于模式的抽象，这样才可以重用上层的业务设计。

如果以面向对象的方式来设计，依赖反转（Dependency Inversion）的解释变为方法不应依赖实现，而是依赖于抽象，实现必须依赖于抽象。来看看下面这个 Java 方法：

public class BusinessObject {

private FloppyWriter writer = new FloppyWriter();

....

public void save() {

...

writer.saveToFloppy();

}

}

在这个方法中，BusinessObject 的存档依赖于实际的 FloppyWriter，如果想要改为存至 USB，则必须修改或继承 BusinessObject，而无法直接使用BusinessObject。

如果通过接口，可以改进这种情况，例如：

public interface IDeviceWriter {

public void saveToDevice();

}

public class BusinessObject {

private IDeviceWriter writer;

public void setDeviceWriter(IDeviceWriter writer) {

this.writer = writer;

}

public void save() {

....

writer.saveToDevice();

}

}

这样一来，BusinessObject 就是可重用的，如果有存储至 Floppy 或 USB的需求，只要继承 IDeviceWriter 即可，而不用修改 BusinessObject：

public class FloppyWriter implement IDeviceWriter {

public void saveToDevice() {

....

// 实际储存至Floppy的方法

}

}

public class UsbDiskWriter implement IDeviceWriter {

public void saveToDevice() {

....

// 实际储存至UsbDisk的方法

}

}

从这个角度来看，Dependency Inversion 的意思即是方法不依赖于实现，而是方法与实现都要依赖于抽象。

IoC 的 Control 是控制的意思，其背后的意义也是一种依赖关系的转移，如果A依赖于B，其意义即是B拥有控制权，想要转移这种关系，所以依赖关系的反转即是控制关系的反转，由控制关系的转移，可以获得组件的可重用性，在上面的 Java 方法中，整个控制权从实际的 FloppyWriter 转移至抽象的 IDeviceWriter 接口上，使得BusinessObject、FloppyWriter、UsbDiskWriter 这几个实现依赖于抽象的 IDeviceWriter 接口。

方法的业务逻辑部分应该是可以重用的，不应受到所使用框架或容器的影响，因为可能转移整个业务逻辑到其他的框架或容器，如果业务逻辑过于依赖容器，则转移至其他的框架或容器时，就会发生困难。

IoC 在容器的角度，可以用一句话来说明——“Don't call me, I'll call you”，就是“不要向

容器要求所需要的（对象）资源，容器会自动将这些对象给你！”。IoC 要求的是容器不侵入方法本身，而方法本身提供好接口，容器可以透过这些接口将所需的资源注入至方法中，方法不向容器主动要求资源，所以不会依赖于容器的组件，方法本身不会意识到正被容器使用，可以随时从容器中脱离转移而不用作任何的修改，而这个特性正是一些业务逻辑中间件最需要的。