URL:http://dev.yesky.com/112/2384612.shtml
Spring框架与AOP思想的研究与应用
2006-05-07 00:00
作者: 梁琳 许向众 洪超
出处: 计算机与信息技术
责任编辑:方舟
摘要 本文对Spring框架中所包含的AOP思想以及事务管理进行了分析,并通过对一个业务对象实现加锁/解锁的操作,说明了动态代理模式的可行性与有效性。
关键词 AOP;横切关注点;控制反转;动态代理
引言
Aspect Oriented Programming(AOP)是近年来计算机技术中比较热门的话题之一。其发展历史从学术领域和研发机构的运用开始,目前流行的Spring应用程序 框架将AOP思想融入了整个框架的设计开发与应用当中。使用Spring框架固然给我们的编程带来了好处与便利,但是同时存在着一个问题,对于初学者来 说,所谓的“控制反转”,不是一个能够望文生义的好名称,“依赖注入”也是一样,也正是因为这样,不少初学者很难在短时间内理解和掌握这些名字和他们的用 法,而要使用AOP的功能也需要理解AOP,也比较难。基于以上原因,我们就会想到,能否简单地将Spring框架中运用到的优秀的理念,巧妙的运用到我 们需要使用的地方,而又绕过不容易上手的Spring框架,做到一举两得呢?本文就将围绕着上述提出的问题给出作者的看法和观点。
AOP思想与面向方面的编程
AOP实际是GoF四人组设计模式的一种扩展,设计模式所追求的是降低代码之间的耦合度,增加程序的灵活性和可重用性,AOP实际上就是设计模式所追求 的目标的一种实现。所谓的分离关注就是将某一通用的需求功能从不相关的类之中分离出来;同时,能够使得很多类共享一个行为,一旦行为发生变化,不必修改很 多类,只要修改这个行为就可以。AOP就是这种实现分散关注的编程方法,它将“关注”封装在“方面”中。
面向对象的编程(OOP)方 法是在面向过程的编程方法基础上进行的改进,而面向方面编程(AOP)方法又是在面向对象编程(OOP)方法的基础上进行改进而来的一种创新的软件开发方 法。AOP和OOP虽然在字面上十分相似,但是却是面向不同领域的两种设计思想。OOP(面向对象编程)针对问题领域中以及业务处理过程中存在的实体及其 属性和操作进行抽象和封装,面向对象的核心概念是纵向结构的,其目的是获得更加清晰高效的逻辑单元划分;而AOP则是针对业务处理过程中的切面进行提取, 例如,某一个操作在各个模块中都有涉及,这个操作就可以看成“横切”存在于系统当中。在许多情况下,这些操作都是与业务逻辑相关性不强或者不属于逻辑操作 的必须部分,而面向对象的方法很难对这种情况做出处理。AOP则将这些操作与业务逻辑分离,使程序员在编写程序时可以专注于业务逻辑的处理,而利用AOP 将贯穿于各个模块间的横切关注点自动耦合进来。AOP所面对的是处理过程中的某个步骤或阶段,对不同的阶段领域加以隔离,已获得逻辑过程中各部分之间低耦 合性的隔离效果,其与面向方面编程在目标上有着本质的差异。AOP的核心思想就是将应用程序中的业务逻辑处理部分同对其提供支持的通用服务,即所谓的“横 切关注点”进行分离,这些“横切关注点”贯穿了程序中的多个纵向模块的需求。
使用AOP机制进行开发,首先要对方面进行了解,将需求 分解成一般关注点和横切关注点,即将核心模块级的关注点和系统级的横切关注点分离;然后各自独立的实现这些关注点;最后用工具将业务逻辑代码和横切关注点 代码编织到一起,形成最终的程序。通过面向方面的编程可以减少编码时间和重复。
目前已经形成的Spring框架
1、Spring框架的特点
Spring框架目前如此流行,一方面的原因在于Spring提供了一套全面并且十分成熟的轻型应用程序基本框架,并且对复杂的应用开发提供了有力的支 持。除此之外,从实际应用开发角度来看,Spring最大的优势在于它是从实际项目开发经验中抽取的,其提供了丰富的类库,可大大节省编码量,它是一种高 效的、可高度重用的应用框架。Spring框架中目前最吸引人也是该应用框架最具特色的地方就是名为控制反转(IOC=Inverse Of Control)或者依赖注入(DI=Dependence Injection)的设计思想,这是一种相当优秀的设计思想,即“好莱坞”原则:不用你主动来找我,我会通知你。但是,仅仅凭借着这样一个单纯的设计模 式并不能使得Spring如此成功,Spring最成功的地方,还是目前使用最为广泛的AOP应用,也就是Spring中基于AOP实现的业务管理机制, 也正是由于这一点,使得Spring AOP成为应用框架中极其闪光的一个亮点。
2、AOP思想在Spring框架中的体现
文章前面已经讲述了AOP的概念以及什么叫做所谓的“横切”关注点,事务管理就是J2EE应用中一个横切多个对象的横切关注点的例子。
2.1 事务管理
对于J2EE应用程序而言,事务的处理一般有两种模式:依赖特定事务资源的事务处理与依赖容器的参数化事务管理。在这里我们略去对第一种处理方式的说明,直接对第二种方式,即依赖容器的参数化事务管理来阐述笔者的观点。
Spring事务管理究竟能带给我们什么?
了解Spring的人们都知道,对于传统的基于事务资源的事务处理而言,Spring并不会产生什么影响,我们照样可以成功编写并且运行这样的代码。
对于依赖容器的参数化事务管理而言,Spring则可以用来帮助实现对事务的管理而无须使用EJB。Spring本身也是一个容器,只是相对EJB容器 所要付出的代价而言,Spring属于轻量级容器,它能够替代EJB,通过使用AOP来提供声明式事务管理,即可通过Spring实现基于容器的事务管理 (从本质上来讲,Spring的事务管理是基于动态AOP)。Spring与EJB最大的区别在于:第一,Spring可以为任意的Java Class实现事务管理而无须转换成标准的EJB;第二,Spring事务管理并不依赖特定的事务资源从而使得系统的应用与部署更佳灵活。
2.2动态代理机制的实现
Spring框架中所提供的AOP支持,是基于动态AOP机制实现的,即通过动态Proxy模式,在目标对象的方法调用前后插入相应的处理代码。AOP 代理可以是基于JDK动态代理,也可以是基于CGLIB代理。Spring默认使用的是基于Java Dynamic Proxy模式实现,这样任何的接口都能被代理。基于Spirng框架的应用程序开发,程序员会有一种自然的倾向性来实现面向接口编程而不是类,业务对象 通常也是实现一个或者多个接口,这也是一种良好的编程习惯。Spring也可以基于CGLIB实现AOP代理,这样所代理的是类而不是接口。如果一个业务 对象没有实现某一个接口,那么CGLIB将被使用。
我们先来分析一下Spring事务管理机制的实现原理。由于Spring内置 AOP默认使用动态代理模式实现,我们就先来分析一下动态代理模式的实现方法。动态代理模式的核心就在于代码中不出现与具体应用层相关联的接口或者类引 用,如上所说,这个代理类适用于任何接口的实现。下面我们来看一个例子。 public class TxHandler implements InvocationHandler {
private Object originalObject; public Object bind(Object obj) { this.originalObject = obj; return Proxy.newProxyInstance(obj.getClass().getClassLoader(),obj.getClass().getInterfaces(),this); }
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { Object result = null; if (!method.getName().startsWith("save")) { UserTransaction tx = null; try { tx = (UserTransaction) (new InitialContext().lookup("java/tx")); result = method.invoke(originalObject, args); tx.commit(); } catch (Exception ex) { if (null != tx) { try { tx.rollback(); } catch (Exception e) { } } } } else { result = method.invoke(originalObject, args); } return result; } } |
下面我们来分析一下上述代码的关键所在。
首先来看一下这段代码:
return Proxy.newProxyInstance( obj.getClass().getClassLoader(),obj.getClass().getInterfaces(),this); |
java.lang.reflect.Proxy.newProxyInstance方法根据传入的接口类型 (obj.getClass.getInterfaces())动态构造一个代理类实例返回,这也说明了为什么动态代理实现要求其所代理的对象一定要实现 一个接口。这个代理类实例在内存中是动态构造的,它实现了传入的接口列表中所包含的所有接口。
再来分析以下代码:
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { …… result = method.invoke(originalObject, args); …… return result; } |
InvocationHandler.invoke方法将在被代理类的方法被调用之前触发。通过这个方法,我们可以在被代理类方法调用的前后进行一些处 理,如代码中所示,InvocationHandler.invoke方法的参数中传递了当前被调用的方法(Method),以及被调用方法的参数。同 时,可以通过method.invoke方法调用被代理类的原始方法实现。这样就可以在被代理类的方法调用前后写入任何想要进行的操作。
Spring的事务管理机制实现的原理,就是通过这样一个动态代理对所有需要事务管理的Bean进行加载,并根据配置在invoke方法中对当前调用的 方法名进行判定,并在method.invoke方法前后为其加上合适的事务管理代码,这样就实现了Spring式的事务管理。Spring中的AOP实 现更为复杂和灵活,不过基本原理是一致的。
3.AOP思想与动态代理模式的应用实例
综上我们分析了Spring框架的事务管理机制的基本现实原理。尽管Spring框架集 中体现了当前流行框架中未曾关注到的一些内容,但是,Spring框架存在晦涩难懂的致命问题。以上通过对Spring框架的一些基本实现原理的研究,给 我们带来了一些启示。我们如果不直接使用庞大的Spring框架,而是将融入Spring框架中的AOP思想直接应用于程序中,既绕过了Spring框架 这个高门槛,又利用了Spring框架中先进的设计理念,这样便达到了一举两得的目的。
下面我们来看一段代码,我们来编写一个Dynamic Proxy based AOP实现的实例。假设现在有一个UserDao接口和以及其实现类UserDaoImp。
UserDAO.java:
public interface UserDAO { public void saveUser(User user); }
UserDAOImp.java:
public class UserDAOImp implements UserDAO{ public void saveUser(User user) { …… } } |
我们需要在saveUser方法中添加对一个业务对象的锁,比如在saveUser前后加锁和解锁。在不影响外部逻辑和不对现有的代码做任何改动的前提 下,代理模式是一个不错的选择。但是如果有多个类似的接口,面对每个接口都要实现一个类似的Proxy,实在是一个烦琐无味的苦力过程。回想一下 Spring在处理这个问题上的设计理念我们不难想到,使用动态代理模式,是这个问题的一个聪明的解决方法。
public class AOPHandler implements InvocationHandler { private static Log logger = LogFactory.getLog(AOPHandler.class); private List interceptors = null; private Object originalObject; public Object bind(Object obj) { this.originalObject = obj; return Proxy.newProxyInstance(obj.getClass().getClassLoader(),obj.getClass().getInterfaces().this); } public Object invoke(Object proxy, Method method, Object[] args) throws Throwable{Object result=null if(method.getName.startsWith(“saveUser”)){ lock(); result=method.invoke(this.originalObject,args); unlock(); } return result; } private void lock(){ logger.info(“lock object!”); } private void unlock(){ logger.info(“unlock object!”); } } |
上述代码中并没有出现与具体应用层相关联的接口以及类的引用,所以对所有的类都适用。这就解决了用静态Proxy类实现所产生的弊端。
总结与展望
以上我们讨论了Spring框架基于动态AOP机制实现以及动态代理机制的应用,围绕着AOP的实现与应用,一直有一个热门的话题,即权限管理。 Spring框架目前对AOP的支持做得相当出色,但是一直有一个尴尬的问题尚未解决,那就是目前还没有一个完备的权限管理组件。仔细想想,这并不是 AOP的瓶颈,而是因为权限管理的形式过于灵活和复杂多变,系统中的权限管理逻辑多种多样各不相同,我们很难做出一个统一的管理与操作。另一方面,权限管 理作为一个独立的切面显得过于庞大,需要进一步切分设计,设计过程复杂,实现难度较大。所以我们还在期待着AOP思想在权限管理方面能有突破性的应用与扩 展。