鹰翔宇空

学习和生活

BlogJava 首页 新随笔 联系 聚合 管理
  110 Posts :: 141 Stories :: 315 Comments :: 1 Trackbacks
引自:http://www.3doing.net/forums/dispbbs.asp?boardID=11&ID=138&page=1


发贴心情 AOP研究

为什么要区分J2EE容器和J2EE应用系统?

  我们知道,J2EE应用系统只有部署在J2EE容器中才能运行,那么为什么划分为J2EE容器和J2EE应用系统? 通过对J2EE容器运行机制的分析(见我的电子教材“EJB实用原理”),我们可以发现:实际上J2EE容器分离了一般应用系统的一些通用功能,例如事务机制、安全机制以及对象池或线程池等性能优化机制。

  这些功能机制是每个应用系统几乎都需要的,因此可以从具体应用系统中分离出来,形成一个通用的框架平台,而且,这些功能机制的设计开发有一定难度,同时运行的稳定性和快速性都非常重要,必须经过长时间调试和运行经验积累而成,因此,形成了专门的J2EE容器服务器产品,如Tomcat JBoss、Websphere、WebLogic等。

  从J2EE系统划分为J2EE容器和J2EE应用系统两个方面,我们已经看到一种分散关注的思路(separation of concerns)。

分散关注

  将通用需求功能从不相关类之中分离出来;同时,能够使得很多类共享一个行为,一旦行为发生变化,不必修改很多类,只要修改这个行为就可以。

   AOP就是这种实现分散关注的编程方法,它将“关注”封装在“方面”中。

AOP是什么?

  AOP是OOP的延续,是Aspect Oriented Programming的缩写,意思是面向方面编程。AOP实际是GoF设计模式的延续,设计模式孜孜不倦追求的是调用者和被调用者之间的解耦,AOP可以说也是这种目标的一种实现。

  举例:假设有在一个应用系统中,有一个共享的数据必须被并发同时访问,首先,将这个数据封装在数据对象中,称为Data Class,同时,将有多个访问类,专门用于在同一时刻访问这同一个数据对象。

  为了完成上述并发访问同一资源的功能,需要引入锁Lock的概念,也就是说,某个时刻,当有一个访问类访问这个数据对象时,这个数据对象必须上锁Locked,用完后就立即解锁unLocked,再供其它访问类访问。

  使用传统的编程习惯,我们会创建一个抽象类,所有的访问类继承这个抽象父类,如下:

abstract class Worker{

  abstract void locked();
  abstract void accessDataObject();
  abstract void unlocked();

}


  缺点:


  • accessDataObject()方法需要有“锁”状态之类的相关代码。


  • Java只提供了单继承,因此具体访问类只能继承这个父类,如果具体访问类还要继承其它父类,比如另外一个如Worker的父类,将无法方便实现。


  • 重用被打折扣,具体访问类因为也包含“锁”状态之类的相关代码,只能被重用在相关有“锁”的场合,重用范围很窄。

    仔细研究这个应用的“锁”,它其实有下列特性:


  • “锁”功能不是具体访问类的首要或主要功能,访问类主要功能是访问数据对象,例如读取数据或更改动作。


  • “锁”行为其实是和具体访问类的主要功能可以独立、区分开来的。


  • “锁”功能其实是这个系统的一个纵向切面,涉及许多类、许多类的方法。如下图:

  因此,一个新的程序结构应该是关注系统的纵向切面,例如这个应用的“锁”功能,这个新的程序结构就是aspect(方面)

  在这个应用中,“锁”方面(aspect)应该有以下职责:

  提供一些必备的功能,对被访问对象实现加锁或解锁功能。以保证所有在修改数据对象的操作之前能够调用lock()加锁,在它使用完成后,调用unlock()解锁。

AOP应用范围

  很明显,AOP非常适合开发J2EE容器服务器,目前JBoss 4.0正是使用AOP框架进行开发。
  具体功能如下:
Authentication 权限
Caching 缓存
Context passing 内容传递
Error handling 错误处理
Lazy loading 懒加载
Debugging  调试
logging, tracing, profiling and monitoring 记录跟踪 优化 校准
Performance optimization 性能优化
Persistence  持久化
Resource pooling 资源池
Synchronization 同步
Transactions 事务

AOP有必要吗?

  当然,上述应用范例在没有使用AOP情况下,也得到了解决,例如JBoss 3.XXX也提供了上述应用功能,但是没有使用AOP。

  但是,使用AOP可以让我们从一个更高的抽象概念来理解软件系统,AOP也许提供一种有价值的工具。可以这么说:因为使用AOP结构,现在JBoss 4.0的源码要比JBoss 3.X容易理解多了,这对于一个大型复杂系统来说是非常重要的。

  从另外一个方面说,好像不是所有的人都需要关心AOP,它可能是一种架构设计的选择,如果选择J2EE系统,AOP关注的上述通用方面都已经被J2EE容器实现了,J2EE应用系统开发者可能需要更多地关注行业应用方面aspect。

AOP具体实现

  AOP是一个概念,并没有设定具体语言的实现,它能克服那些只有单继承特性语言的缺点(如Java),目前AOP具体实现有以下几个项目:

  AspectJ (TM): 创建于Xerox PARC. 有近十年历史,成熟
  缺点:过于复杂;破坏封装;需要专门的Java编译器。

  动态AOP:使用JDK的动态代理API或字节码Bytecode处理技术。

 动态AOP:使用JDK的动态代理API或字节码Bytecode处理技术。

  基于动态代理API的具体项目有:
  JBoss 4.0 JBoss 4.0服务器
  nanning 这是以中国南宁命名的一个项目,搞不清楚为什么和中国相关?是中国人发起的?

  基于字节码的项目有:
  aspectwerkz 
  spring 
在以后其它文章中,我将继续对AOP概念进行分析,和大家一起学习进步。

发贴心情 

AOP和AspectJ

板桥里人http://www.jdon.com 2004/01/10

需求和问题

  以上篇《AOP是什么》中并发访问应用为例子:

  多个访问类同时访问一个共享数据对象时,每个访问类在访问这个数据对象时,需要将数据对象上锁,访问完成后,再实行解锁,供其它并发线程访问,这是我们处理并发访问资源的方式。

  为了实现这个需求,先实现传统的编程,这里我们假定有一个写锁,对数据对象实行写之前,首先对这个对象进行上写锁,写操作完毕后,必须释放写锁。

  首先,我们需要一个锁,这个锁可以是数据对象中一个字段或其它,这里使用Doug Lea的ReentrantWriterPreferenceReadWriteLock作为我们的锁资源。

import EDU.oswego.cs.dl.util.concurrent.*;

public class Worker extends Thread {

  Data data;

  ReentrantWriterPreferenceReadWriteLock rwl = 
    new ReentrantWriterPreferenceReadWriteLock();

  public boolean createData() {
   try {
    rwl.writeLock().acquire(); //上锁

    //对data实行写逻辑操作 
       
   }catch() {
     return false;
   }finally{
     rwl.writeLock().release();  //解锁
   }
   return true;
  }

  public boolean updateData() {
   try {
    rwl.writeLock().acquire();//上锁

    //对data实行写逻辑操作 
       
   }catch() {
     return false;
   }finally{
     rwl.writeLock().release(); //解锁
   }
   return true;
  }

  public void run() {
    //执行createData()或updateData()
  }
}

假设可能存在另外一个访问类,也将对数据对象实现写操作,代码如下:

import EDU.oswego.cs.dl.util.concurrent.*;

public class AnotherWorker extends Thread {

  Data data;

  ReentrantWriterPreferenceReadWriteLock rwl = 
    new ReentrantWriterPreferenceReadWriteLock();
  
  public boolean updateData() {
   try {
    rwl.writeLock().acquire();//上锁

    //对data实行写逻辑操作 
       
   }catch() {
     return false;
   }finally{
     rwl.writeLock().release(); //解锁
   }
   return true;
  }

  public void run() {
    //执行updateData()
  }
}

  以上是Java传统编程的实现,这种锁的实现方式是在每个具体类中实现,如下图:

这种实现方式的缺点很多:

  • 冗余:有很多重复的编码,如rwl.writeLock().acquire()等;
  • 减少重用:worker的updateData()方法重用性几乎为零。
  • "数据对象写操作必须使用锁控制这个设计目的"不容易显现,如果更换了一个新的程序员,他可能编写一段不使用锁机制就对这个数据对象写操作的代码。
  • 如果上述代码有读功能,那么我们需要在代码中实现先上读锁,当需要写时,解读锁,再上写锁等等,如果稍微不小心,上锁解锁次序搞错,系统就隐含大的BUG,这种可能性会随着这个数据对象永远存在下去,系统设计大大的隐患啊!

  那么我们使用AOP概念来重新实现上述需求,AOP并没有什么新花招,只是提供了观察问题的一个新视角度。

  这里我们可以抛开新技术迷人雾障,真正核心还是新思维、新视点,人类很多问题如果换一个脑筋看待理解,也许结果真的是翻天覆地不一样啊,所以,作为人自身,首先要重视和你世界观和思维方式不一样的人进行交流和沟通。

  现实生活中有很多"不公平",例如某个小学毕业生成了千万富翁,你就怀疑知识无用,也许你认为他的机会好,其实你可能不知道,他的观察问题的视角比你独特,或者他可能会经常换不同的角度来看待问题和解决问题,而你由于过分陷入一个视角的具体实现细节中,迷失了真正的方向,要不说是读书人脑子僵化呢?

  言归正传,我们看看AOP是如何从一个新的视角解决上述问题的。

  如果说上面代码在每个类中实现上锁或解锁,类似横向解决方式,那么AOP是从纵向方面来解决上述问题,纵向解决之道示意图如下:

  AOP把这个纵向切面cross-cuts称为Aspect(方面),其实我认为AOP翻译成面向切面编程比较好,不知哪个糊涂者因为先行一步,翻译成“面向方面编程”如此抽象,故弄玄虚。

AspectJ实现

  下面我们使用AOP的实现之一AspectJ来对上述需求改写。AspectJ是AOP最早成熟的Java实现,它稍微扩展了一下Java语言,增加了一些Keyword等,pointcut的语法如下:

public pointcut 方法名:call(XXXX)

  AspectJ增加了pointcut, call是pointcut类型,有关AspectJ更多基本语法见这里。因为AspectJ使用了一些特别语法,所以Java编译器就不能用SUN公司提供javac了,必须使用其专门的编译器,也许SUN在以后JDK版本中会引入AOP。

  使用AspectJ如何实现上图所谓切面式的编程呢?首先,我们将上图纵向切面称为Aspect,那么我们建立一个类似Class的Aspect,Java中建立一个Class代码如下:

public class MyClass{
  //属性和方法 ...
}

  同样,建立一个Aspect的代码如下:

public aspect MyAspect{
  //属性和方法 ...
}

建立一个Aspect名为Lock,代码如下:

import EDU.oswego.cs.dl.util.concurrent.*;

public aspect Lock {

  ......
  ReentrantWriterPreferenceReadWriteLock rwl = 
    new ReentrantWriterPreferenceReadWriteLock();

  public pointcutwriteOperations():
    execution(public boolean Worker.createData()) ||
    execution(public boolean Worker.updateData()) ||
    execution(public boolean AnotherWorker.updateData()) ;


  before() : writeOperations() {
    rwl.writeLock().acquire();//上锁 advice body
  }

  after() : writeOperations() {
     rwl.writeLock().release(); //解锁 advice body
  }

  ......
}

  上述代码关键点是pointcut,意味切入点或触发点,那么在那些条件下该点会触发呢?是后面红字标识的一些情况,在执行Worker的createData()方法,Worker的update方法等时触发。

  before代表触发之前做什么事情?
  答案是上锁。

  after代表触发之后做什么事情?
  答案是上锁。

  通过引入上述aspect,那么Worker代码可以清洁如下:

public class Worker extends Thread {

  Data data;

  public boolean createData() {
   try {
    //对data实行写逻辑操作        
   }catch() {
     return false;
   }
   return true;
  }

  public boolean updateData() {
   try {
    //对data实行写逻辑操作        
   }catch() {
     return false;
   }finally{
   }
   return true;
  }

  public void run() {
    //执行createData()或updateData()
  }
}

  Worker中关于“锁”的代码都不见了,纯粹变成了数据操作的主要方法。

AOP术语

  通过上例已经知道AspectJ如何从切面crosscutting来解决并发访问应用需求的,其中最重要的是引入了一套类似事件触发机制。

  Pointcut类似触发器,是事件Event发生源,一旦pointcut被触发,将会产生相应的动作Action,这部分Action称为Advice。

  Advice在AspectJ有三种:before、 after、Around之分,上述aspect Lock代码中使用了Advice的两种before和after。

  所以AOP有两个基本的术语:Pointcut和Advice。你可以用事件机制的Event和Action来类比理解它们。上述并发访问应用中pointcut和advice如下图所示:

小结如下:
advice - 真正的执行代码,或者说关注的实现。 类似Action。
join point - 代码中激活advice被执行的触发点。
pointcut - 一系列的join point称为pointcut,pointcut有时代指join point

其中advice部分又有:
Interceptor - 解释器并没有在AspectJ出现,在使用JDK动态代理API实现的AOP框架中使用,解释有方法调用或对象构造或者字段访问等事件,是调用者和被调用者之间的纽带,综合了Decorator/代理模式甚至职责链等模式。

Introduction - 修改一个类,以增加字段、方法或构造或者执行新的接口,包括Mixin实现。

例如上述并发访问应用中,如果想为每个Data对象生成相应的aspect Lock,那么可以在aspect Lock中人为数据对象增加一个字段lock,如下:

aspect Lock {

  Data sharedDataInstance;
  Lock( Data d ) {
     sharedDataInstance = d;
  }

  introduce Lock Data.lock; //修改Data类,增加一字段lock

  advise Data() { //Data构造时触发
     static after {
       //当Data对象生成时,将Data中lock字段赋值为aspect Lock
       //为每个Data对象生成相应的aspect Lock
       thisObject.lock = new Lock( thisObject );
     }
   }
  ....

}

上述代码等于在Data类中加入一行:

public class Data{
  ......
  Lock lock = new Lock();
  ......
}

还有其它两个涉及AOP代码运行方式:

weaving - 将aspect代码插入到相应代码中的过程,一般是编译完成或在运行时动态完成。取决于具体AOP产品,例如AspectJ是使用特殊编译器在编译完成weaving,而nanning、JBoss AOP是使用动态代理API,因此在运行时动态完成weaving的。
instrumentor - 用来实现weaving功能的工具。

发贴心情 

AOP与权限控制实现

板桥里人http://www.jdon.com 2004/01/10

  以往在J2EE系统中,访问权限控制系统的实现主要有两种:应用程序实现和J2EE容器实现。

传统的应用程序实现

  这是最直接的、传统的一种解决方式,通常是在具体方法前加一个权限判断语句,如下:

public class ForumFactoryProxy extends ForumFactory {
  ......
  public Forum createForum(String name, String description)
    throws UnauthorizedException, ForumAlreadyExistsException
  {
    if (permissions.get(ForumPermissions.SYSTEM_ADMIN)) {
      Forum newForum = factory.createForum(name, description);
      return new ForumProxy(newForum, authorization, permissions);
    }else {
      throw new UnauthorizedException();
    }
  }
  ......
}

  上述代码是Jive论坛中一段创建论坛功能的代码,在创建论坛前,首先进行权限角色检验,如果当前用户是系统管理员,那么可以实现真正的创建。

  这种在具体功能前加入权限操作检验的实现方式有很多缺点:
  1.每个功能类都需要相应的权限检验代码,将程序功能和权限检验混淆在一起,存在紧密的耦合性,扩展修改难度大。
  2.如果类似Jive,以代理模式为每个功能类实现一个相应的代理类,虽然解耦了程序功能和权限检验,但是,从某个角色的权限检验这个切面考虑,涉及具体Proxy类太多,扩展修改难度大。

J2EE容器实现

  在AOP概念没有诞生前,J2EE规范已经提供了关于权限控制的容器实现标准,这种变迁结果如下图所示:

  原来需要每个应用程序实现的权限Proxy转为整个容器的Proxy实现,其中JDK1.3以后的动态代理API为这种转换实现提供了技术保证。

  非常明显,通过容器实现权限控制验证可以大大简化应用程序的设计,分离了应用系统的权限关注,将权限控制变成了对J2EE容器服务器的配置工作,具体技术细节参考我的书籍《Java实用系统开发指南》第六章。

  其实,容器的权限实现也是一种从一个切面来解决问题方式,AOP概念诞生后,权限控制实现由此也带来了两个方向的变化:
  1. J2EE容器级别的权限实现,也就是容器自身的权限实现。
  2. J2EE应用程序级别的权限实现。

  权限控制在容器级别实现似乎使得J2EE开发者感觉没有灵活性和可扩展性,其实象JBoss 4.0这样的J2EE容器,由于引入了AOP概念,使得J2EE开发者在自己的应用系统中能够直接操纵容器的一些行为。容器和应用系统由于AOP引入的Aspect切面,变得可以成为一体了。(如果使用BEA的EJBC编辑要浪费多少时间?)

  对于J2EE应用系统开发者,能够做到上述境界,必须的条件是对JBoss之类J2EE容器必须有足够的了解,因为这些方式并不是J2EE标准,有可能在移植到新的J2EE容器,这些知识和投入变得无用(也有可能将来J2EE扩展其标准)。

  很显然,使用AOP实现J2EE应用系统级别的权限控制,是解决上述移植风险的一个主要方法,但是带来的缺点是必须亲自从零开始做起,耗费时间不会很短。

AOP下的应用程序权限控制实现

  引入AOP概念后的权限实现已经不是前面Jive实例那样“落后”,我们对这个实例进行重整(Refactorying)如下:

创建一个Aspect,专门用于权限检查,如下:

private static aspect PermissionCheckAspect {

  private pointcut permissionCheckedExecution() :
   execution ( public Forum ForumFactory.createForum(String , String ));

  before () : permissionCheckedExecution() {
    if !(permissions.get(ForumPermissions.SYSTEM_ADMIN)) {
      throw new UnauthorizedException();
    }
   }

}

该段代码功能是:当系统运行ForumFactory.createForum方法之前,将首先检查是否有权限操作。

代码中pointcut触发的条件是createForum方法执行,如果有其它需要系统管理员身份才能执行的方法加入,将写成如下代码:

private pointcut permissionCheckedExecution() :
   execution ( public Forum ForumFactory.createForum(String , String )) ||
   execution ( public Forum ForumFactory.deleteForum(String , String )) ||
   ......
   execution ( public Forum ForumFactory.deleteThread(String , String ));

这些方法陈列比较琐碎,依据AspectJ语法,可以简化如下:
private pointcut permissionCheckedExecution() :
   execution ( public * ForumFactory .*(..));

有兴趣者可以将Jive论坛中相关权限Proxy部分使用AOP重整,另外,由于Jive没有引入角色概念,导致权限和用户HardCode在编码中,如何实现权限和用户解耦,最小限度的降低HardCode量,角色概念在其中起着不可忽视的重要作用。这是另外一个研究课题了。

发贴心情 

Ioc模式

板桥里人http://www.jdon.com 2004/01/31

  分离关注( Separation of Concerns : SOC)是Ioc模式和AOP产生最原始动力,通过功能分解可得到关注点,这些关注可以是 组件Components, 方面Aspects或服务Services。

  从GoF设计模式中,我们已经习惯一种思维编程方式:Interface Driven Design 接口驱动,接口驱动有很多好处,可以提供不同灵活的子类实现,增加代码稳定和健壮性等等,但是接口一定是需要实现的,也就是如下语句迟早要执行:

  AInterface a = new AInterfaceImp();

  AInterfaceImp是接口AInterface的一个子类,Ioc模式可以延缓接口的实现,根据需要实现,有个比喻:接口如同空的模型套,在必要时,需要向模型套注射石膏,这样才能成为一个模型实体,因此,我们将人为控制接口的实现成为“注射”。

  Ioc英文为 Inversion of Control,即反转模式,这里有著名的好莱坞理论:你呆着别动,到时我会找你。

  其实Ioc模式也是解决调用者和被调用者之间的一种关系,上述AInterface实现语句表明当前是在调用被调用者AInterfaceImp,由于被调用者名称写入了调用者的代码中,这产生了一个接口实现的原罪:彼此联系,调用者和被调用者有紧密联系,在UML中是用依赖 Dependency 表示。

  但是这种依赖在分离关注的思维下是不可忍耐的,必须切割,实现调用者和被调用者解耦,新的Ioc模式 Dependency Injection 模式由此产生了, Dependency Injection模式是依赖注射的意思,也就是将依赖先剥离,然后在适当时候再注射进入。

Ioc模式(Dependency Injection模式)有三种:

第一种类型从JNDI或ServiceManager等获得被调用者,这里类似ServiceLocator模式。1. EJB/J2EE
2. Avalon(Apache的一个复杂使用不多的项目)
第二种类型使用JavaBeans的setter方法1. Spring Framework,
2. WebWork/XWork
第三种类型在构造方法中实现依赖1. PicoContainer,
2. HiveMind

  有过EJB开发经验的人都知道,每个EJB的调用都需要通过JNDI寻找到工厂性质的Home接口,在我的教程EJB是什么章节中,我也是从依赖和工厂模式角度来阐述EJB的使用。

  在通常传统情况下,为了实现调用者和被调用者解耦,分离,一般是通过工厂模式实现的,下面将通过比较工厂模式和Ioc模式不同,加深理解Ioc模式。

工厂模式和Ioc

  假设有两个类B 和 C:B作为调用者,C是被调用者,在B代码中存在对C的调用:

public class B{
   private C comp;
  ......
}

  实现comp实例有两种途径:单态工厂模式和Ioc。

工厂模式实现如下:

public class B{
   private C comp;
  private final static MyFactory myFactory = MyFactory.getInstance();

  public B(){
    this.comp = myFactory.createInstanceOfC();

  }
   public void someMethod(){
    this.comp.sayHello();
  }
  ......
}

特点:

  • 每次运行时,MyFactory可根据配置文件XML中定义的C子类实现,通过createInstanceOfC()生成C的具体实例。

使用Ioc依赖性注射( Dependency Injection )实现Picocontainer如下,B类如同通常POJO类,如下:

public class B{
   private C comp;
  public B(C comp){
    this.comp = comp;
   }
   public void someMethod(){
    this.comp.sayHello();
   }
  ......
}

假设C接口/类有有一个具体实现CImp类。当客户端调用B时,使用下列代码:

public class client{
   public static void main( String[] args ) {
    DefaultPicoContainer container = new DefaultPicoContainer();
    container.registerComponentImplementation(CImp.class);
    container.registerComponentImplementation(B.class);
    B b = (B) container.getComponentInstance(B.class);
    b.someMethod();
   }
}

  因此,当客户端调用B时,分别使用工厂模式和Ioc有不同的特点和区别:

  主要区别体现在B类的代码,如果使用Ioc,在B类代码中将不需要嵌入任何工厂模式等的代码,因为这些工厂模式其实还是与C有些间接的联系,这样,使用Ioc彻底解耦了B和C之间的联系。

  使用Ioc带来的代价是:需要在客户端或其它某处进行B和C之间联系的组装。

  所以,Ioc并没有消除B和C之间这样的联系,只是转移了这种联系。
  这种联系转移实际也是一种分离关注,它的影响巨大,它提供了AOP实现的可能。

Ioc和AOP

  AOP我们已经知道是一种面向切面的编程方式,由于Ioc解放自由了B类,而且可以向B类实现注射C类具体实现,如果把B类想像成运行时的横向动作,无疑注入C类子类就是AOP中的一种Advice,如下图:

  通过下列代码说明如何使用Picocontainer实现AOP,该例程主要实现是记录logger功能,通过Picocontainer可以使用简单一行,使所有的应用类的记录功能激活。

首先编制一个记录接口:

public interface Logging {

  public void enableLogging(Log log);

}

有一个LogSwitcher类,主要用来激活具体应用中的记录功能:

import org.apache.commons.logging.Log;
public class LogSwitcher
{
  protected Log m_log;
  public void enableLogging(Log log) {
    m_log = log;
    m_log.info("Logging Enabled");
  }
}

一般的普通应用JavaBeans都可以继承这个类,假设PicoUserManager是一个用户管理类,代码如下:

public class PicoUserManager extends LogSwitcher
{

  ..... //用户管理功能
}
public class PicoXXXX1Manager extends LogSwitcher
{

  ..... //业务功能
}
public class PicoXXXX2Manager extends LogSwitcher
{

  ..... //业务功能
}

注意LogSwitcher中Log实例是由外界赋予的,也就是说即将被外界注射进入,下面看看使用Picocontainer是如何注射Log的具体实例的。


DefaultPicoContainer container = new DefaultPicoContainer();
container.registerComponentImplementation(PicoUserManager.class);
container.registerComponentImplementation(PicoXXXX1Manager.class);
container.registerComponentImplementation(PicoXXXX2Manager.class);
.....

Logging logging = (Logging) container.getComponentMulticaster();

logging.enableLogging(new SimpleLog("pico"));//激活log

  由上代码可见,通过使用简单一行logging.enableLogging()方法使所有的应用类的记录功能激活。这是不是类似AOP的advice实现?

  总之,使用Ioc模式,可以不管将来具体实现,完全在一个抽象层次进行描述和技术架构,因此,Ioc模式可以为容器、框架之类的软件实现提供了具体的实现手段,属于架构技术中一种重要的模式应用。J道的JdonSD框架也使用了Ioc模式。




posted on 2006-06-01 09:42 TrampEagle 阅读(458) 评论(0)  编辑  收藏 所属分类: java

只有注册用户登录后才能发表评论。


网站导航: