虽然看了一阵子书，可以依然感觉Spring非常抽象。
Spring的介绍：
引出：
依赖注入。 方式有： 构造器 注入。（+面向接口）实现松耦合。
创建应用组件（对象）之间协作的行为 称为装配。 即 注入 叫做装配。
常见的是通过XML 配置文件。
AOP
struts2的拦截器是用来过滤页面请求，页面请求到达action前会被过滤器拦截，
而AOP实际是GOF设计模式的延续，设计模式孜孜不倦追求的是调用者和被调用者之间的解耦，主要是用来解决OOP和过程方法不能够很好解决的横切（crosscut）问题。
http://blog.csdn.net/shendl/article/details/526362
横切关注点的两种实现方法
软件系统，可看作由一组关注点组成。其中，直接的业务关注点，是直切关注点。而 为 直切关注点 提供服务的，就是横切关注点。
有两种方法可以提供横切关注点，一种是传统的OOP方法，提供一个与直切关注点的实现一样的类来提供服务。另一种是最新的AOP方法，提供一个Aspect方面（Spring AOP中叫advisor顾问）来提供服务。
OOP方式是：业务类使用对象引用，使用“委派”的方式，调用横切类的方法（服务）。
这是“主叫”式的服务。业务类用显示代码来呼叫服务。这在业务类中增加了与“直切关注点”概念无关的代码，破坏了封装性，增加了业务类和服务之间的耦合。
AOP方式是：提供一个Aspect方面，这个方面的概念类似于“类”，它封装了“横切关注点”的实现代码。并且还提供了“切入点”。切入点是“连接点”的集合。切入点就是定义了Aspect方面为哪些类的哪些方法提供服务。（其实，就是把需要服务的对象，集成到了服务端，而不是业务端的主叫的方式。）
AOP的实现方式有很多种。最早的方式是编译时织入。AspectJ就是使用这种方式。AspectJ的特殊编译器将业务类和Aspect方面的代码组装在一起，从而实现服务的无缝接入。这种方式，源代码中的业务方法和Aspect方面无关。
另一种很典型、很精巧的实现方式是使用动态代理模拟实现AOP。这是现在最流行的方式。JBoss AOP框架和Spring AOP框架都使用这种方式。
这里我介绍一下Spring AOP框架提供横切关注点服务的方式。编写一个方面，这个方面也是一个一般的pojo类,但是它需要提供一个接口。
然后，使用Advisor顾问（就是方面，是方面+切入点）进行配置，配置接口和切入点模式。在程序运行到连接点方法时，构建一个动态代理类，返回一个谧名的java类，而不是直接使用业务类。这个谧名类组装了业务类和Advise建议（就是方面，SpringAOP的术语）。
由此可见，AOP实现横切关注点的方式要比OOP方式好得多。
而在AOP实现中，我更欣赏Spring AOP 这样运用动态代理模式实现的AOP。这种方式不需要任何辅助工具即可开发AOP。
但是，对于开发AOP也要注意一点： Spring AOP的advice代码只能够在连接点方法之前、之后调用，或者在异常被抛出之后调用。
这样，就要求我们的目标方法（就是连接点，Advice要捆在它上面）必须够小，要把一个大方法分割成多个小方法。这就需要“重构”技术来帮忙。当然，这不是什么缺点，反而是一个让你养成好习惯的机会。“面向方法重构！”
AOP这种技术的提出是一个了不起的成就。这个技术的始作俑者AspectJ本身的实现技术十分笨拙。
AOP思想实际上是一个软件设计思想的发展，“横切关注点”的发现，使施乐的科学家们创造了AOP这样一种“面向方面（横切关注点）编程”的思想。也使他们生造出了笨拙的怪胎AspectJ。而另一些也在苦苦思索OOP面临问题的一线程序高手，立刻从AOP思想中获得久久寻找中的解决之道。
他们从设计模式中翻出了“动态代理模式”和“装修者模式”，用她们优雅的实现了JBossAOP,SpringAOP这样的pojo型的AOP解决方案！
Spring到底是个什么东西？