我来说说Bean的使用方法

核心提示：最近讨论主要围绕在公共构造函数以及工厂模式身上，我在此分贴，我来说说Bean的使用方法，说说我对 Bean的看法，因为最近项目使用到了webwork，那么这一切优雅的实现就断节了，就算要实现这么一个类似的实现，sPRing，hibernate

　　最近讨论主要围绕在公共构造函数以及工厂模式身上。我在此分贴，说说我对 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格式，也就是说没有公开构造器，那么这一切优雅的实现就断节了，就算要实现这么一个类似的实现，也要需要花费大量的精力物力来填补构造器的模式。