当前位置导航:炫浪网>>网络学院>>编程开发>>JAVA教程>>Java进阶

我来说说Bean的使用方法


  最近讨论主要围绕在公共构造函数以及工厂模式身上。我在此分贴,说说我对 Bean的看法。因为最近项目使用到了webwork,spring,hibernate。我主要结合这些框架来谈谈我个人对pojo bean的认识。
  bean的规范使得对象属性填充得到动态支持,Bean的规范使得对象图的建立非常清晰。OGNL正是基于此实现。
  在对bean属性赋值 与 bean的定义之间插入一个中间层OGNL,得到最大限度的灵活。我们举一个比较极端但确实经常发生的例子(顺带狠狠批一下Struts)。
  
  java代码:
  
  1
  2  // 持久层entity:
  3 public class BeanA{
  ...}
  4  private String name;
  5  private int number;
  6  public BeanA(){
  ...}
  7  }
  8  public String getName(){
  ...}
  9return name;
  10  }
  11  public void setName(String name){
  ...}
  12   this.name=name;
  13  }
  14  public int getNumber(){
  ...}
  15   return number;
  16  }
  17  public void setNumber(int num){
  ...}
  18   number=num;
  19  }
  20 }
  21
  22 //视图层form:
  23 Struts:
  24 public class BeanAForm{
  ...}
  25  private String name;
  26  private String number;
  27  public BeanA(){
  ...}
  28  }
  29  public String getName(){
  ...}
  30   return name;
  31  }
  32  public void setName(String name){
  ...}
  33   this.name=name;
  34  }
  35  public String getNumber(){
  ...}
  36   return number;
  37  }
  38  public void setNumber(String num){
  ...}
  39   number=num;
  40  }
  41 }
  42
  
  struts通过form定义利用bean的特性达到form的自动填充,然后通过beanutil将form转到entity或者DTO。
  某天,客户觉得需要修改entity,增多一个字段bar,struts的做法是修改form,修改entity,修改配置文件的form定义,修改客户端jsp文件等等,然后编译通过,update database schema。
  webwork的做法就非常简单了,在open session in filter模式下,只需改动
  entity的定义即可,ognl将所有的问题变得简单得可怕。
  OGNL完全将客户端到服务器端的参数传递代理了,只要你在你的action定义相应的name setter,ognl自动识别到这个setter,自动将参数传递进来。
  对于多层关联的情况,最极端的如下:
  
  java代码:
  1
  2 public class A{
  ...}
  3  private B b;
  4  //getter
  5  //setter
  6 };
  7 public class B{
  ...}
  8  private C c;
  9  //getter setter
  10 };
  11 public class C{
  ...}
  12  String name;
  13
  14 };
  
  你在视图层只暴露了A对象,而需要通过form修改C对象的值,这种情况在struts我不知道它怎么实现,但是在webwork下,依赖OGNL,您要做的仅仅写下这么一句:name="a.b.c.name" 。Ognl自动将name的值填充到c的属性。
  讨论了这么多,回过头来看,是什么东西使得我们web开发变得简单了呢?是OGNL,那么OGNL为什么这么强大呢?因为OGNL是基于Bean的对象图寻找方式!!
  到这里,我们看到了Bean是一切的基础,没有bean就没有OGNL。
  同样,看看IoC容器,一样的道理,没有Bean就没有IoC容器的实现。如果采用bean的格式定义你的组件, 那么意味着你的组件是可装配的,如果采用bean定义的entity,意味着你的entity是可以自动填充的。
  现在评价一个软件好坏,可装配性是一个重要目标。假设一个较复杂得系统,我们分析一下它的运作:
  A系统由 子系统C 子系统B 构成,子系统C 由C1,C2,C3等等服务组件构成,每个服务组件又需要调用多个基本服务类来协作。子系统B同样构架。
  
  系统启动过程:
  bootrap启动服务守护引擎,引擎读取配置文件,相关初始化。
  
  服务过程:
  一个请求上来,守护引擎根据请求映射,需要调用C子系统的服务接口,C子系统的服务接口未装载,请求beanfactory装载C子系统的服务接口,beanfactory读取C系统接口配置,发现这个接口具体实现类,以及这个具体实现类需要到的C1,C2,C3组件,又根据引用读取C1等的配置信息,知道最后的服务类是最简单的POJO bean。逐一初始化所有需要用到的类,然后调用已经实例化的接口,完成服务。
  
  改动过程:
  C1,C2组件需要改善功能,增加C4,C5组件。写代码,编译打包,修改配置文件,发布。
  服务过程如上
  
  这个系统是完全可插入的,因为它所有的服务过程都是基于组件的,组件是可装配的。试想一下,如果其中的C1或者C2不是Bean格式,也就是说没有公开构造器,那么这一切优雅的实现就断节了,就算要实现这么一个类似的实现,也要需要花费大量的精力物力来填补构造器的模式。
  
相关内容
赞助商链接