转载：理解Spring OC 与& AOP 的

原文：http://bjxwind.blog.163.com/blog/static/315935712010219101037713/

1、Spring IOC

    IoC 与 DI

　　 首先想说说 IoC （ Inversion of Control ，控制倒转）。这是 spring 的核心，贯穿始终。所谓IoC ，对于 spring 框架来说，就是由 spring 来负责控制对象的生命周期和对象间的关系。这是什么意思呢，举个简单的例子，我们是如何找女朋友的？常见的情况是，我们到处去看哪里有长得漂亮身材又好的 mm，然后打听她们的兴趣爱 好、 qq 号、电话号、 ip 号、 iq 号 ……… ，想办法认识她们，投其所好送其所要，然后嘿嘿 ……这个过程是复杂深奥的，我们必须自己设计和面对每个环节。传 统的程序开发也是如此，在一个对象中，如果要使用另外的对象，就必须得到它（自己new 一个，或者从 JNDI 中查询一个），使用完之后还要将对象销毁（比 如 Connection等），对象始终会和其他的接口或类藕合起来。

　　那么 IoC是如何做的呢？有点像通过婚介找女朋友，在我和女朋友之间引入了一个第三者：婚姻介绍所。婚介管理了很多男男女女的资料，我可以向婚介提出一个列表，告诉它我想找个什么样的女朋友，比如长得像李嘉欣，身材像林熙雷，唱歌像周杰伦，速度像卡洛斯，技术像齐达内之类的，然后婚介就会按照我们的要求，提供一个 mm，我们只需要去和她谈恋爱、结婚就行了。简单明了，如果婚介给我们的人选不符合要求，我们就会抛出异常。整个过程不再由我自己控制，而是有婚介这样一个类似容器的机构来控制。 Spring 所倡导的开发方式就是如此，所有的类都会在 spring 容器中登记，告诉spring 你是个什 么东西，你需要什么东西，然后 spring会在系统运行到适当的时候，把你要的东西主动给你，同时也把你交给其他需要你的东西。所有的类的创建、销毁都由 spring来控制，也就是说控制对象生存周期的不再是引用它的对象，而是 spring。对于某个具体的对象而言，以前是它控制其他对象，现在是所有对象 都被 spring控制，所以这叫控制反转。如果你还不明白的话，我决定放弃。

IoC 的一个重点是在系统运行中，动态的向某个对象提供它所需要的其他对象。这一点是通过 DI （ DependencyInjection ，依赖注入）来实现的。比如对象 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 ）；将依赖关系作为构造子参数传入的做法称为构造子注入（ Constructor Injection ）。

 

2、Spring AOP

　　2.1 面向切面编程基础

　　通常，系统由很多组件组成，每个组件负责一部分功能，然而，这些组件也经常带有一些除了核心功能之外的附带功能。系统服务如日志、事务管理和安全经常融入到一些其他功能模块中。这些系统服务通常叫做交叉业务，这是因为它们总是分布在系统的很多组件中。通过将这些业务分布在多个组件中，给我们的代码引入了双重复杂性。

　　(1)实现系统级业务的代码在多个组件中复制。这意味着如果你要改变这些业务逻辑，你就必须到各个模块去修改。就算把这些业务抽象成一个独立模块，其它模块只是调用它的一个方法，但是这个方法调用也还是分布在很多地方。

　　(2)组件会因为那些与自己核心业务无关的代码变得杂乱。一个向地址录中添加条目的方法应该只关心如何添加地址，而不是关心它是不是安全或支持事务的。

　　此时，我们该怎么办呢？这正是AOP用得着的地方。AOP帮助我们将这些服务模块化，并把它们声明式地应用在需要它们的地方，使得这些组件更加专注于自身业务，完全不知道其它涉及到的系统服务。

　　这里的概念切面，就是我们要实现的交叉功能，是应用系统模块化的一个方面或领域。切面的最常见例子就是日志记录。日志记录在系统中到处需要用到，利用继承来重用日志模块是不合适的，这样，就可以创建一个日志记录切面，并且使用AOP在系统中应用。

 

2.2 AOP在Spring中的实现

　　基于AOP，业界 存在各种各样的AOP实现，比如，JBossAOP、Spring AOP、ASP ectJ、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能够很方便的使用到非常健壮、灵活的企业级服务，是因为SpringAOP能够提供如下几方面的优势：

　　（1）允许开发者使用声明式企业服务，比如事务服务、安全性服务；EJB 开发者都知道，EJB组件能够使用J2EE容器提供的声明式服务，但是这些服务要借助于EJB容器，而SpringAOP却不需要EJB容器，借助于Spring的事务抽象框架就可以这些服务。

　　（2）开发者可以开发满足业务需求的自定义切面；

　　（3）开发Spring AOP Advice很方便。因为这些AOPAdvice仅是POJO类，借助于Spring提供的ProxyFactoryBean,能够快速的搭建Spring AOPAdvice。

转载于:https://www.cnblogs.com/leeeee/p/7276578.html