当Endisoft爱上了JAVA
I believe I can fly,I can touch the sky
posts - 4,  comments - 1,  trackbacks - 0
有人说spring aop+ spring ioc, 才~~~是spring
简单一点,是一个容器. 什么容器,容纳什么?是对象,或者说bean的容器.
那为什么叫轻量级容器呢?相对于EJB container,使用spring不需要写符合容器规范的代码,即容器不会"侵入"了你的代码.

这个容器会提供你的应用(程序)中用到的所有对象,并对这些对象进行统一的生命周期管理和组装.在通常的开发中,我们在需要某个对象的时候只是 new MyObject(). 在Java中,这样没有什么不好,因为gc会打理好"善后"工作,是系统级的. 而用spring,在需要某个对象时,只要向容器请求相应的对象,spring会找到并准备好这些对象并提供给你.她也会打理好"善后"工作,但是是在应用级的.
另一方面,spring还会帮助你打理对象之间的依赖关系.
比如原来的做法:

class A{
}
class B{
  A a ;
  public B(){ a = new A();}
}

而使用spring的做法
class A{
}
class B{
  A a;
  public B(){}
  void setA(A a){this.a=a}
  A getA(){return this.a}
}
(希望你不要单纯地认为spring会写很多代码)
但从前一个方面,你可能觉得spring只是一个对象容器.从这里你就应该看出,spring是bean容器,因为spring需要你的类符合bean规范:相应于每一个成员域,都需要提供setter和getter方法.spring要使用这些方法来注入依赖关系,也就是 dependence injection, 或者inversion of control. 我个人觉得还是di更容易理解,直到现在我还是要考虑怎么去向别人很好的解释ioc.控制反转(倒转),我的理解是就如同上面的两个例子里看到的,依赖(控制)不在体现在代码逻辑里(如第一个例子),而是在配置文件里,而在代码中我们只提供注入点(也就是setter和getter).

希望我对IoC的概念的讲解能够给你一些启发.
你可能要问了,为什么我要这样做呢?原来的做法有什么不妥的地方么?没有什么不妥,只是两种理念而已,没有绝对的好还是不好,但我还是给你我的解释--我理解的IoC的好处,希望有所帮助.通常在程序设计的时候,我们在需要某些功能时,会相应的去设计一些方法,然后根据OO去将方法和一成员变量组成一个类.实际上,我们最终设计出的程序是:一组类的实例互相交互完成某个特定的任务.
除了一些核心的业务方法,以外我们还要做组装对象的工作.比如我有了一个工厂,里面有很多机器,机器在开动时要装配相应的模具.那么在工厂的生产过程中, 首先我要有工厂,机器,模具这样三个类.然后我的"动作"有:装配,开机.通常的做法我们要做装配,然后再去开机.而用spring,我们只是专注于开机.这样我们就把装配这个动作抽离出了核心的"生产过程".当某些机器改变了装配模具时,不在需要修改核心业务代码.这就是解耦.如:

public class Production{
  public static void main(String[] args){
    Factory factory = (Factory)BeanFactory.getBean("factory");
    factory.launchProduction();
  }
}

class Factory{
  Machine machine1,machine2;
  void launchProduction(){
     machine1.start(); machine2.start();
  }
  // setters and getters
}

class Machine{
  Tool tool;
  void start(){
  }
  // setters and getters
}

在launchProduction()方法中只需要开动每台机器即可.而不需要每次都装配机器.装配的工作交给了别人.现在只要按下start按钮.生产就开始了!要是原来:

void launchProduction(){
  machine1 = new MachineA();
  machine1.setTool(new ToolA());
  machine2 = new MachineB();
  machine2.setTool(new ToolB());
  machine1.start();
  machine2.start();
}

这就是工作分工,是不是感觉轻松了许多?从此以后,我们都是面向构件去开发,而不需要过多地在代码中体现构件之间的依赖关系.

AOP
推荐你看一下<<effective enterprise java>>的第一章,对AOP有很清晰,易懂的解释.其实AOP并非很艰深晦涩的概念,但是从架构角度去理解她的重要性可能不是我这样的new fish一时半会儿可以领悟到的.
我这里只是想说,有些概念你要知道是怎么回事,但理解到多深,除了天赋以外更多的是经验和悟.所以不要心急.--像是在自我解嘲.
也许在不知不觉中你就使用了很多AOP的概念,比如servlet里的filter,比如在写一个command类时,给她的调用类在每次调用command时前后加上:preProcess和postProcess...
我不想解释太多,<<eej>>的解释已经足够.
posted on 2006-09-26 23:31 Endisoft 阅读(1184) 评论(0)  编辑  收藏

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


网站导航:
 

<2006年9月>
272829303112
3456789
10111213141516
17181920212223
24252627282930
1234567

常用链接

留言簿(1)

随笔档案(4)

文章分类(5)

文章档案(3)

类的初始化

最新随笔

搜索

  •  

积分与排名

  • 积分 - 5150
  • 排名 - 3048

最新评论

阅读排行榜

评论排行榜