spring框架的IOC和AOP机制模拟

从我接触到的两个项目,这两个项目真的很大。但它们的的确确用到了spring进行事务控制,同时其中一个中时整合了struts2和spring。虽然两个框架都是开源的,也是人们所说的轻量级j2ee所使用的组件,但其中的思想却是值得我们学习和使用的。

以下想就spring的IOC(DI)和AOP两个重要的概念通过实践进行理解,以期对spring有一个新的认识。

 

1、IOC

      貌似通常说的DI方式有三种,但其中两种并不常用,对用setter方法的注入倒是使用的很频繁,也可以说是很成熟,那就以这个做为对IOC和理解进行实例演示。

 

        首先来看一下我用作测试的整个工程的目录结构:

        

 

 

      1)IOC依赖于一个配置文件beans,这个配置文件也是在服务器启动时就需要加载到内存中的,如果想知道如何在web工程中加载配置文件可以看我博客中《模拟struts架构》描述。beans.xml文件存储于src的根目录。

 

         让我们看下beans文件的内容:

          一个简单的xml文件,其中模仿spring的配置文件进行了相关的配置,如果学习过spring的同学应该很容易看懂其中内容,如果没学习过的,那就当作xml来看待就好了,如果xml也不知道,那还是先补一下吧。

 

         

 

 

  2)看一下在beans.xml文件中所涉及到的类:

其实这些类基本都是javabean,不过对用UserService类一看就知道了,此类是要用做业务处理的,必然有还相应的业务处理方法。而这个业务处理类,如果需要用到数据模型(也就是javabean),那这里(业务处理类)就需要声明一个数据模型的对象,那这个对象由谁来创建呢,我们交由spring来给我们创建,那这个创建的过程由我们手中交到了spring手中,这种产品类对象的方式就是所谓的IOC(控制反转),而生成这一对象后如何交给业务处理使用,我们采用set方法将对象初始化给业务处理类中已定义但未创建的对象,这一个过程就是DI(依赖注入)。ok,到这里我们就明白了什么是IOC和DI,这两个概念是经常被人们所谈到的。

 

业务处理类UserService.java

 

 

 

 

将会用作被注入到业务处理类中的类UserDAOImpl.java和它的父类UserDAO.java

 

 

 

 

 

不要忘记了这个javabean

 

 

 

再回过头来看一下这几个类的关系,DAO类将会被注入到业务类中进行数据持久化,而刚才所说的数据模型却并没有作为注入的对象,原因是对于项目架构的设计,并不会将所以的类都进行注入,那样并没有太大的意义,而一些对于业务分层出现明显界线的会使用注入的方式进行管理,而javabean对于整个业务处理流程都会用到,如果进行注入就不合适了。这点很重要,不然我们使用这种框架一方面帮助我们加快开发速度,一方面是由于它从使用的方式上就可以让我们的项目各层次之间使用最少的耦合。

 

3)真正实现注入

 

之前的代码只是我们自己在项目中会写到的,主要是让大家注意到在写代码过程中一些地方用来做什么的,另一些地方又用来做什么的。下面是真正的实现了注入。以下内容大概是这样的:从我们的模拟的配置文件中读取内容到内存(注:这里使用jdom的方式)。然后按照配置文件中的内容产生类的实例,并将这个实例注入到依赖它的那个类里(这里其实就是执行了一个setXXX(Object)方法,但这个方法名和方法的参数及这个set方法的调用都是我们亲手根据配置文件一步一步来做的)。

当然这里还提供了一个getBean()方法,这个方法供我们传入相应的bean的名称,得到相应的类的实例,模拟的还是很真实的,且像类名和实现的接口都是依照spring而来的,与spring中的名称一样。

 

 

 

 

 

 

4)测试

 

这里使用junit进行测试我们写的效果,你可以打印相应语句看看我们模拟的怎么。

 

 

 

2、AOP

 

这一个概念不需要在实践的过程就应该能理解,其实就是在我们的业务流程中(这个流程打个比方是一条直线),然后我们在第1厘米和第10厘米处分别打了两个记号,这样你的流程就不得不经过我们的记号再住下执行。这就是AOP(切面)的大致理解。

 

 

所以可以这样说,我们如果要是想在执行一个方法的前面和后面都加入日志打印,那我们的通常想法是再写两个方法,一个在调用原来的方法前调用 ,一个在执行后调用 ,这样也是AOP的现实例子。那我们又应该如何来模拟呢,我们还是以这个记日志的例子为例来模拟,如果这个成功了那就可以改为事务的处理。那不就是我们常用的AOP的最好实践么。

 

再提示一上,设计模式中有一种模式叫做代理,而我们想的是让程序根据要执行的方法而打印出不同的日志,那你会想到什么,动态代理。对,我们就是想用动态代理来模拟AOP。

 

知道了这一利害,那就直接让我们看代码吧:

 

 

类中的invoke方法是必须要有这,在invoke方法中我们调用了beforeMethod方法,这个就打印出了方法执行前的日志,然后执行真正要执行的方法。这里没有调用类似afterMethod这样的方法,因为原理都是一样的。

这样就真的将我的想要组合在一起的两方法捆绑好了。那如何才能让他们一起执行呢。

 

看这里,这里让他们一起执行:

如果对于代理模式及反射熟悉的话,应该很好理解。这里直接在单元测试里产生代理的调用,从而让被代理也一起调用了

 

 

 

 

总结:

 

spring的这两个机制不管是在实际运用中还是面试中都需要我们深入的了解,那样才会事半功倍。我希望我们通过实践对这两个概念也好机制也好都有新的理解才是最好。

 

 

 

  • 2
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 3
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值