Spring中两大核心组成:IOC&DI,AOP.AOP最大的用处在于事务处理上,
使用MyElipse开发项目对于所有的AOP几乎不需要做太多的处理.由开发工具帮助用户自己完成了,而在整个学习过程之中,掌握AOP的编程的核心理念要比实现更为重要.
在整个的开发之中曾经强调过,业务层在项目之中要负责以下的操作:
●调用数据层进行处理;
●调用事务的处理;
●关闭数据库的操作连接.
如果说现在以一个数据的增加操作为例
那么这样的结构就相当于所有的操作都使用了硬编码的形式完成.类似于如下形式
范例:增加处理
package cn.zwb.service.impl;
public class MemberServiceImpl {
public boolean insert(){
//1.执行日志处理;
//2.调用数据层操作;
//3.进行事务的提交处理;
//4.数据库的关闭操作;
return false;
}
}
在之前的代码都是这样完成处理的,但实际上这样并不好,因为整个的业务层只关心处理的核心操作;
就好比一个人去外面吃饭,只关注于吃饭的本身,但是让这个顾客又买菜,又做饭,又吃饭,又自己刷碗收拾,基本上这样的操作就属于一塌糊涂.
如果现在你的开发之中遇见了许多这样要编写非业务处理的功能的时候,又该怎么解决呢?于是首先想到的就是代理设计模式,让代理设计模式完成所有的辅助性操作,而后静态代理会有类型限制,应该使用使用动态代理机制完成
而且同时在整个的设计过程之中并不只是一个简单的代理类就可以完成所有的操作功能,需要考虑如下几种情况:
●在数据层调用之前如何执行(执行数据层之前进行记录)
●在数据层调用之后如何执行(执行执行数据库之后手工进行事务的提交);
●在业务层操作完成之后返回结果上进行处理;
●还有可能出现异常之后需要进行记录.
这么一看要想准确的实现代理设计操作,至少需要四个处理类,这四个类的关系如何处理呢?于是最早的时候(JDK1.5之前)为了可以处理这样的问题,引入了一系列的Advice操作接口形式,
所有的类都写完之后利用Spring的配置文件将这些操作完整的融合在一起,这样当业务层调用时,会自动触发以上的操作子类进行依次的执行
但是如果这样编写代码会有以下缺点:
●Spring本身就是一个容器,而以上的操作需要使用明确的接口以及明确的实现子类来明确的定义;而这样一来结构又固定了,希望可以让定义这些代理操作的时候不受到接口的限制,于是在Spring接下来的版本之中开始使用Annocation的配置模式解决了此类问题;也就是利用特定的注解来描述具体的代理操作方法的作用.
任何的开发都应该避免强烈的耦合性问题,尤其是在Spring之中;最大的特点在于String类的操作上,所以为了解决硬编码的方式配置代理结构是强烈不建议使用的,那么在Spring之中引入了Apache推出的AspectJ操作的语法形式,以字符串的形式定义代理操作的切入点.并且使用一系列的通配符来找到所需要进行切入的操作程序.
那么现在实际上就可以得出就一个结论,如果要想实现一个优秀的代理设计模式,那么必须要使用面向方面的编程,即"将不同的切入点代码单独定义,而后组织在一个程序网上.所以这就构成了整个AOP编程的理论来源,而在整个AOP之中包含有如下几个重要的组成概念:
●切入点:可以理解为所有要操作的方法定义,要求业务层的方法必须统一风格,
●分离点:将那些不可再分的组件单独提取出去定义为单独的操作功能,
●横切关注点:指的是将所有与开发无关的概念完全的程序组成类单独提取而后组织运行
●织入:将所有的切入点,关注点的代码组成在一张完整的程序结构之中,而Spring就完成了这样的组织操作;
但是并不是意味着所有的操作都由用户放肆的去定义切入点,在整个Spring里面依然采用通知的形式完成,也就是说当触发到了某些操作之后那么就自然进行一些固定的处理,所以在整个SpringAOP之中包含有如下的几类通知形式:
●前置通知(Before Advice):在某一操作执行之前负责处理;
●后置通知(After Advice):在某一操作执行之后负责处理,但是后置通知需要考虑以下几种子类:
|-后置返回通知(After Returning Advice):负责处理返回结果的时候进行拦截
|-后置异常通知(After Throwing Advice):当出现异常之后进行拦截
|-后置最终通知(After Finally Advice):不管执行到最后是否出现异常,都会执行拦截
●环绕通知(Around Advice):可以在具体的执行操作之前,之后,异常出现处理等地方任意编写,可以说是包含了如上的几种通知的综合体.