Spring框架的7个模块
Spring 框架是一个分层架构，由 7 个定义良好的模块组成。Spring 模块构建在核心容器之上，核心容器定义了创建、配置和管理 bean 的方式，组成 Spring 框架的每个模块（或组件）都可以单独存在，或者与其他一个或多个模块联合实现。每个模块的功能如下：
核心容器(Spring Core)：核心容器提供 Spring 框架的基本功能。核心容器的主要组件是 BeanFactory，它是工厂模式的实现。BeanFactory 使用控制反转 （IOC）模式将应用程序的配置和依赖性规范与实际的应用程序代码分开。
Spring 上下文(Spring Context)：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 的核心两点
1.Spring IOC
首先说说IoC（Inversionof Control，控制反转）。这是spring的核心，贯穿始终。所谓IoC，对于spring框架来说，就是由spring来负责控制对象的生命周期和对象间的关系。这是什么意思呢，举个简单的例子，我们是如何找女朋友的？常见的情况是，我们到处去看哪里有长得漂亮身材又好的mm，然后打听她们的兴趣爱 好、qq号、电话号、ip号、iq号………，想办法认识她们，投其所好送其所要，然后嘿嘿……这个过程是复杂深奥的，我们必须自己设计和面对每个环节。传 统的程序开发也是如此，在一个对象中，如果要使用另外的对象，就必须得到它（自己new一个，或者从JNDI中查询一个），使用完之后还要将对象销毁（比如Connection等），对象始终会和其他的接口或类藕合起来。
那么IoC是如何做的呢？有点像通过婚介找女朋友，在我和女朋友之间引入了一个第三者：婚姻介绍所。婚介管理了很多男男女女的资料，我可以向婚 介提出一个列表，告诉它我想找个什么样的女朋友，比如长得像李嘉欣，身材像林熙雷，唱歌像孙燕姿，声音像林志玲，身材像柳岩，然后婚介就会按照我 们的要求，提供一个mm，我们只需要去和她谈恋爱、结婚就行了。简单明了，如果婚介给我们的人选不符合要求，我们就会抛出异常。整个过程不再由我自己控 制，而是有婚介这样一个类似容器的机构来控制。Spring所倡导的开发方式就是如此，所有的类都会在spring容器中登记，告诉spring你是个什 么东西，你需要什么东西，然后spring会在系统运行到适当的时候，把你要的东西主动给你，同时也把你交给其他需要你的东西。所有的类的创建、销毁都由 spring来控制，也就是说控制对象生存周期的不再是引用它的对象，而是spring。对于某个具体的对象而言，以前是它控制其他对象，现在是所有对象 都被spring控制，所以这叫控制反转。它用到了设计模式中的工厂模式。如果你还不明白的话，我决定放弃。
IoC的一个重点是在系统运行中，动态的向某个对象提供它所需要的其他对象。这一点是通过DI（Dependency Injection，依赖注入）来实现的。比如对象A需要操作数据库，以前我们总是要在A中自己编写代码来获得一个Connection对象，有了spring我们就只需要告诉spring，A中需要一个Connection，至于这个Connection怎么构造，何时构造，A不需要知道。在系统 运行时，spring会在适当的时候制造一个Connection，然后像打针一样，注射到A当中，这样就完成了对各个对象之间关系的控制。A需要依赖 Connection才能正常运行，而这个Connection是由spring注入到A中的，依赖注入的名字就这么来的。那么DI是如何实现的呢？ Java 1.3之后一个重要特征是反射（reflection），它允许程序在运行的时候动态的生成对象、执行对象的方法、改变对象的属性，spring就是通过反射来实现注入的。关于反射的相关资料请查阅java doc。
IoC是一个很大的概念，可以用不同的方式来实现。主要的实现形式有两种:
依赖查找：容器提供回调接口和上下文环境给组件。EJB和Apache Avalon都是使用这种方式。
依赖注入：组件不做定位查询，只是提供普通的Java方法让容器去决定依赖关系。容器全权负责组件的装配，它会把符合依赖关系的对象通过JavaBean属性或者构造子传递给需要的对象。通过JavaBean属性注射依赖关系的做法称为设值方法注入（SetterInjection）；将依赖关系作为构造子参数传入的做法称为构造子注入（ConstructorInjection）。核心就是通过反射注入
ps：1.这里的组件指自己的代码，容器指的就是spring，ejb之类的
到这里，大家应该对IoC与DI都有了初步的认识了。其实就Spring来说，就是JavaBean由Spring来管理组装，表面上看就少了几个new字，其实就是为了降低耦合度，这也是我们做软件的目标之一。
2、Spring AOP
2.1 面向切面编程
通常，系统由很多组件组成，每个组件负责一部分功能，然而，这些组件也经常带有一些除了核心功能之外的附带功能。系统服务如日志、事务管理和安全经常融入到一些其他功能模块中。这些系统服务通常叫做交叉业务，这是因为它们总是分布在系统的很多组件中。通过将这些业务分布在多个组件中，给我们的代码引入了双重复杂性。
(1) 实现系统级业务的代码在多个组件中复制。这意味着如果你要改变这些业务逻辑，你就必须到各个模块去修改。就算把这些业务抽象成一个独立模块，其它模块只是调用它的一个方法，但是这个方法调用也还是分布在很多地方。
(2) 组件会因为那些与自己核心业务无关的代码变得杂乱。一个向地址录中添加条目的方法应该只关心如何添加地址，而不是关心它是不是安全或支持事务的。
此时，我们该怎么办呢？这正是AOP用得着的地方。AOP帮助我们将这些服务模块化，并把它们声明式地应用在需要它们的地方，使得这些组件更加专注于自身业务，完全不知道其它涉及到的系统服务。
这里的概念切面，就是我们要实现的交叉功能，是应用系统模块化的一个方面或领域。切面的最常见例子就是日志记录。日志记录在系统中到处需要用到，利用继承来重用日志模块是不合适的，这样，就可以创建一个日志记录切面，并且使用AOP在系统中应用。下图展示了切面应用方式
图表 1 应用切面
其中，通知Advice是切面的实际实现。连接点Joinpoint是应用程序执行过程中插入切面的地点，这个地点可以是方法调用，异常抛出，甚至可以是要修改的字段，切面代码在这些地方插入到你的应用流程中，添加新的行为。切入点Pointcut定义了Advice应该应用在那些连接点，通常通过指定类名和方法名，或者匹配类名和方法名式样的正则表达式来指定切入点。
2.2 AOP在Spring中的实现
基于AOP，业界存在各种各样的AOP实现，比如，JBoss AOP、Spring AOP、ASPectJ、AspectWerkz等。各自实现的功能也不一样。AOP实现的强弱在很大程度上取决于连接点模型。目前，Spring只支持方法级的连接点。这和一些其他AOP框架不一样，如AspectJ和JBoss，它们还提供了属性接入点，这样可以防止你创建特别细致的通知，如对更新对象属性值进行拦截。然而，由于Spring关注于提供一个实现J2EE服务的框架，所以方法拦截可以满足大部分要求，而且Spring的观点是属性拦截破坏了封装，让Advice触发在属性值改变而不是方法调用上无疑是破坏了这个概念。
Spring的AOP框架的关键点如下：
（1）Spring实现了AOP联盟接口。在Spring AOP中，存在如下几种通知（Advice）类型
Before通知：在目标方法被调用前调用，涉及接口org.springFramework.aop.MethodBeforeAdvice;
After通知：在目标方法被调用后调用，涉及接口为org.springframework.aop.AfterReturningAdvice;
Throws通知：目标方法抛出异常时调用，涉及接口org.springframework.aop.MethodBeforeAdvice;
Around通知：拦截对目标对象方法调用，涉及接口为org.aopalliance.intercept.MethodInterceptor。
（2）用Java编写Spring通知，并在Spring的配置文件中，定义在什么地方应用通知的切入点。
（3）Spring的运行时通知对象。代理Bean只有在第一次被应用系统需要的时候才被创建。如果你使用的是ApplicationContext，代理对象在BeanFactory载入所有Bean的时候被创建。Spring有两种代理创建方式。如果目标对象实现了一个或多个接口暴露的方法，Spring将使用JDK的java.lang.reflect.Proxy类创建代理。这个类让Spring动态产生一个新的类，它实现所需的接口，织入了通知，并且代理对目标对象的所有请求。如果目标对象没有实现任何接口，Spring使用CGLIB库生成目标对象的子类。在创建这个子类的时候，Spring将通知织入，并且将对目标对象的调用委托给这个子类。此时，需要将Spring发行包lib/cglib目录下的JAR文件发布到应用系统中。
2.3 Spring AOP的优势
借助于Spring AOP，Spring IoC能够很方便的使用到非常健壮、灵活，可维护性高的的企业级服务，是因为Spring AOP能够提供如下几方面的优势：
（1）允许开发者使用声明式企业服务，比如事务服务、安全性服务；EJB开发者都知道，EJB组件能够使用J2EE容器提供的声明式服务，但是这些服务要借助于EJB容器，而Spring AOP却不需要EJB容器，借助于Spring的事务抽象框架就可以这些服务。
（2）开发者可以开发满足业务需求的自定义切面；
（3）开发Spring AOP Advice很方便。因为这些AOP Advice仅是POJO类，借助于Spring提供的ProxyFactoryBean,能够快速的搭建Spring AOP Advice。
（4）AOP并没有帮助我们解决任何新的问题，它只是提供了一种更好的办法，能够用更少的工作量来解决现有的一些问题，使得系统更加健壮，可维护性更好。
PS：
1.AOP的实现就是两种，动态代理，和静态代理，动态代理就是上面使用的jdk的Proxy和CGLIB里面的，自己也自己实现了动 态代理的笔记设计模式-----结构模式-代理模式，AOP实现的更加精巧，因为使用jdk的Proxy不能代理类只能代理接口，于是对非接 口的类的代理使用CGLIB开源来实现
2.动态代理与静态代理区别
静态代理：由程序员创建，再对其编译。在程序运行之前.class文件已经存在了。
动态代理：在程序运行时，运用反射的机制动态创建而完成。无需程序员手动编写代码，利用jdk的动态代理机制即可，不仅简化了编程工作，且提高了软件的可扩展性，因为java的反射机制可以生成任意类型的动态代理。
动态代理使用场景：不允许直接访问某些类，对访问要做特殊处理；或者对原始方法进行统一的扩展，例如日志的记录。
说说Spring的事务传播机制
Spring中事务声明方式：1、基于XML配置：在applicationContext.xml中对类的方法统一配置；2、注解式（@Transactional），事务的propagation 的7种传播行为：
1： PROPAGATION_REQUIRED
如果当前没有事务，就新建一个事务，如果已经存在一个事务中，加入到这个事务中。这是 最常见的选择。
比如说，ServiceB.methodB的事务级别定义为PROPAGATION_REQUIRED, 那么由于执行ServiceA.methodA的时候，
ServiceA.methodA已经起了事务，这时调用ServiceB.methodB，ServiceB.methodB看到自己已经运行在ServiceA.methodA
的事务内部，就不再起新的事务。而假如ServiceA.methodA运行的时候发现自己没有在事务中，他就会为自己分配一个事务。
这样，在ServiceA.methodA或者在ServiceB.methodB内的任何地方出现异常，事务都会被回滚。即使ServiceB.methodB的事务已经被提交，但是ServiceA.methodA在接下来fail要回滚，ServiceB.methodB也要回滚
2： PROPAGATION_SUPPORTS
支持当前事务，如果当前没有事务，就以非事务方式执行。
3： PROPAGATION_MANDATORY
使用当前的事务，如果当前没有事务，就抛出异常。
4： PROPAGATION_REQUIRES_NEW
新建事务，如果当前存在事务，把当前事务挂起。
这个就比较绕口了。 比如我们设计ServiceA.methodA的事务级别为PROPAGATION_REQUIRED，ServiceB.methodB的事务级别为PROPAGATION_REQUIRES_NEW，
那么当执行到ServiceB.methodB的时候，ServiceA.methodA所在的事务就会挂起，ServiceB.methodB会起一个新的事务，等待ServiceB.methodB的事务完成以后，
他才继续执行。他与PROPAGATION_REQUIRED 的事务区别在于事务的回滚程度了（PROPAGATION_REQUIRED是只要方法A方法调用B方法，无论两个这调用关联的方法是不是有两个或者一个事务，只要其中一个方法出现异常，就都会回滚，而PROPAGATION_REQUIRES_NEW则不一样，方法调用关联，分开事务，但是如果其中有一个事务出现异常回滚，它不会影响跟这个方法调用关联的其它方法的事务）。因为ServiceB.methodB是新起一个事务，那么就是存在
两个不同的事务。如果ServiceB.methodB已经提交，那么ServiceA.methodA失败回滚，ServiceB.methodB是不会回滚的。如果ServiceB.methodB失败回滚，如果他抛出的异常被ServiceA.methodA捕获，ServiceA.methodA事务仍然可能提交。
5： PROPAGATION_NOT_SUPPORTED
以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
当前不支持事务。比如ServiceA.methodA的事务级别是PROPAGATION_REQUIRED ，而ServiceB.methodB的事务级别是PROPAGATION_NOT_SUPPORTED ，
那么当执行到ServiceB.methodB时，ServiceA.methodA的事务挂起，而他以非事务的状态运行完，再继续ServiceA.methodA的事务。
6： PROPAGATION_NEVER
以非事务方式执行，如果当前存在事务，则抛出异常。
不能在事务中运行。假设ServiceA.methodA的事务级别是PROPAGATION_REQUIRED， 而ServiceB.methodB的事务级别是PROPAGATION_NEVER ，
那么ServiceB.methodB就要抛出异常了。
7： PROPAGATION_NESTED
如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与 PROPAGATION_REQUIRED 类似的操作。
理解Nested的关键是savepoint。他与PROPAGATION_REQUIRES_NEW的区别是，PROPAGATION_REQUIRES_NEW另起一个事务，将会与他的父事务相互独立，
而Nested的事务和他的父事务是相依的，他的提交是要等和他的父事务一块提交的。也就是说，如果父事务最后回滚，他也要回滚的。
而Nested事务的好处是他有一个savepoint。