javabean、DTO、VO

一.javabean

一、 javabean 是什么？

Bean的中文含义是“豆子”，顾名思义，JavaBean是指一段特殊的Java类，

就是有默然构造方法,只有get,set的方法的java类的对象.

专业点解释是：

JavaBean定义了一组规则
JavaBean就是遵循此规则的平常的Java对象

满足这三个条件:  
   1.执行java.io.Serializable 接口 
　2.提供无参数的构造器 
  3.提供getter 和 setter方法访问它的属性.

简单地说，JavaBean是用Java语言描述的软件组件模型，其实际上是一个类。这些类遵循一个接口格式，以便于使函数命名、底层行为以及继承或实现的行为，可以把类看作标准的JavaBean组件进行构造和应用。

JavaBean一般分为可视化组件和非可视化组件两种。可视化组件可以是简单的GUI元素，如按钮或文本框，也可以是复杂的，如报表组件；非可视化组件没有GUI表现形式，用于封装业务逻辑、数据库操作等。其最大的优点在于可以实现代码的可重用性。JavaBean又同时具有以下特性。

易于维护、使用、编写。

可实现代码的重用性。

可移植性强，但仅限于Java工作平台。

便于传输，不限于本地还是网络。

可以以其他部件的模式进行工作。

对于有过其他语言编程经验的读者，可以将其看作类似微软的ActiveX的编程组件。但是区别在于JavaBean是跨平台的，而ActiveX组件则仅局限于Windows系统。总之，JavaBean比较适合于那些需要跨平台的、并具有可视化操作和定制特性的软件组件。

JavaBean组件与EJB（Enterprise JavaBean，企业级JavaBean）组件完全不同。EJB 是J2EE的核心，是一个用来创建分布式应用、服务器端以及基于Java应用的功能强大的组件模型。JavaBean组件主要用于存储状态信息，而EJB组件可以存储业务逻辑。

2  使用JavaBean的原因

程序中往往有重复使用的段落，JavaBean就是为了能够重复使用而设计的程序段落，而且这些段落并不只服务于某一个程序，而且每个JavaBean都具有特定功能，当需要这个功能的时候就可以调用相应的JavaBean。从这个意义上来讲，JavaBean大大简化了程序的设计过程，也方便了其他程序的重复使用。

JavaBean传统应用于可视化领域，如AWT（窗口工具集）下的应用。而现在，JavaBean更多地应用于非可视化领域，同时，JavaBean在服务器端的应用也表现出强大的优势。非可视化的JavaBean可以很好地实现业务逻辑、控制逻辑和显示页面的分离，现在多用于后台处理，使得系统具有更好的健壮性和灵活性。JSP + JavaBean和JSP + JavaBean + Servlet成为当前开发Web应用的主流模式。

3  JavaBean的开发

在程序设计的过程中，JavaBean不是独立的。为了能够更好地封装事务逻辑、数据库操作而便于实现业务逻辑和前台程序的分离，操作的过程往往是先开发需要的JavaBean，再在适当的时候进行调用。但一个完整有效的JavaBean必然会包含一个属性，伴随若干个get/set（只读/只写）函数的变量来设计和运行的。JavaBean作为一个特殊的类，具有自己独有的特性。应该注意以下3个方面。

JavaBean类必须有一个没有参数的构造函数。

JavaBean类所有的属性最好定义为私有的。

JavaBean类中定义函数setXxx() 和getXxx()来对属性进行操作。其中Xxx是首字母大写的私有变量名称。

二.DTO

什么是DTO

在分布式系统中，客户端和服务器端交互有两种情形：第一个是客户端从服务器端读取数据；第二个是客户端将本身的数据传递给服务器端。

当有客户端要向服务器端传输大量数据的时候，可以通过一个包含要传输的所有数据的方法调用来完成。这在小数据量的时候缺点并不明显，但是如果要传递包含有大量信息的数据的时候，这将变得难以忍受。下面的方法是任何人看了都会害怕的：

public void save(String id,String number,String name,int type,int height,

int width,BigDecimal weight,BigDecimal price,String description)

这种接口也是非常的脆弱，一旦需要添加或者删除某个属性，方法的签名就要改变。

当客户端要从服务器端取得大量数据的时候，可以使用多个细粒度的对服务器端的调用来获取数据。比如：

ISomeInterface intf = RemoteService.getSomeInterface();

System.out.println("您要查询的商品的资料为:");

System.out.println("编号："+intf.getNumber(id));

System.out.println("姓名："+intf.getName(id));

System.out.println("类型："+intf.getType(id));

System.out.println("高度："+intf.getHeight(id));

System.out.println("宽度："+intf.getWidth(id));

System.out.println("价格："+intf.getPrice(id));

System.out.println("描述信息："+intf.getDescription(id));

这种方式中每一个get***方法都是一个对服务器 的远程调用，都需要对参数和返回值进行序列化和反序列化，而且服务器进行这些调用的时候还需要进行事务、权限、日志的处理，这会造成性能的大幅下降。如果 没有使用客户端事务的话还会导致这些调用不在一个事务中从而导致数据错误。

系统需要一种在客户端和服务器端之间高效、安全地进 行数据传输的技术。DTO(Data Transfer Object，数据传送对象)是解决这个问题的比较好的方式。DTO是一个普通的Java类，它封装了要传送的批量的数据。当客户端需要读取服务器端的数 据的时候，服务器端将数据封装在DTO中，这样客户端就可以在一个网络调用中获得它需要的所有数据。

还是上面的例子，服务器端的服务将创建一个DTO并封装客户端所需要的属性，然后返回给客户端：

ISomeInterface intf = RemoteService.getSomeInterface();

SomeDTOInfo info = intf.getSomeData(id);

System.out.println("您要查询的商品的资料为:");

System.out.println("编号："+info.getNumber());

System.out.println("姓名："+info.getName());

System.out.println("类型："+info.getType());

System.out.println("高度："+info.getHeight());

System.out.println("宽度："+info.getWidth());

System.out.println("价格："+info.getPrice());

System.out.println("描述信息："+info.getDescription());

使用DTO 的时候，一个主要问题是选择什么样的DTO：这个DTO能够容纳哪些数据，DTO的结构是什么，这个DTO是如何产生的。DTO是服务器端和客户端进行通 信的一个协议格式，合理的DTO设计将会使得服务器和客户端的通信更加顺畅。在水平开发模式(即每个开发人员负责系统的不同层，A专门负责Web表现层的 开发，B专门负责服务层的开发)中，在项目初期合理的DTO设计会减少各层开发人员之间的纠纷；在垂直开发模式(即每个开发人员负责不同模块的所有层，A 专门负责库存管理模块的开发，B专门负责固定资产模块的开发)中，虽然开发人员可以自由地调整DTO的结构，但是合理的DTO设计仍然会减少返工的可能 性。

实现DTO 最简单的方法是将服务端的域对象(比如Hibernate中的PO、EJB中的实体Bean)进行拷贝然后作为DTO传递。采用域对象做DTO比较简单和 清晰，因为DTO与域模型一致，所以了解一个结构就够了。这样做也免去了DTO的设计，使得开发工作变得更快。这种做法的缺点是域DTO的粒度太大以至于 难以满足客户端的细粒度的要求，客户端可能不需要访问那些域中的所有属性，也可能需要不是简单地被封装在域中的数据，当域DTO不能满足要求的时候就需要 更加细粒度的DTO方案。目前主流的DTO解决方案有定制DTO、数据传送哈希表、数据传送行集。

10.2  域DTO

域模型是指从业务模型中抽取出来的对象模型，比如商品、仓库。在J2EE中，最常见的域模型就是可持久化对象，比如Hibernate中的PO、EJB中的实体Bean。

在分布式系统中，域模型完全位于服务器端。根据持久 化对象可否直接传递到客户端，域对象可以分为两种类型：一种是服务器端的持久化对象不可以直接传递到客户端，比如EJB中的实体Bean是不能被传递到客 户端的；一种是持久化对象可以直接传递到客户端，比如Hibernate中的PO变为detached object以后就可以传递到客户端。

EJB中的实体Bean不能直接传递到客户端，而且实体Bean不是一个简单的JavaBean，所以也不能通过深度克隆(deep clone)创造一个新的可传递Bean的方式产生DTO。针对这种情况，必须编写一个简单的JavaBean来作为DTO。

下面是一个系统用户的实体Bean的代码：

 abstract public class SystemUserBean implements EntityBean
 {
     EntityContext entityContext;
     public java.lang.String ejbCreate(java.lang.String userId)
             throws CreateException
     {
         setUserId(userId);
         return null;
     }
     public void ejbPostCreate(java.lang.String userId)
             throws CreateException
     {
     }
     public void ejbRemove() throws RemoveException
     {
     }
     public abstract void setUserId(java.lang.String userId);
     public abstract void setName(java.lang.String name);
     public abstract void setPassword(java.lang.String password);
     public abstract void setRole(java.lang.Integer role);
     public abstract java.lang.String getUserId();
     public abstract java.lang.String getName();
     public abstract java.lang.String getPassword();
     public abstract java.lang.Integer getRole();
     public void ejbLoad()
     {
     }
     public void ejbStore()
     {
     }
     public void ejbActivate()
     {
     }
     public void ejbPassivate()
     {
     }
     public void unsetEntityContext()
     {
         this.entityContext = null;
     }
     public void setEntityContext(EntityContext entityContext)
     {
         this.entityContext = entityContext;
     }
 }

DTO生成器

将PO经过一定形式的转换，传递给客户端，使得客户端能够方便地使用传过来的DTO，这就是DTO生成器要解决的问题。把问题具体分解，我们发现DTO生成器的功能如下：

l   允许客户端指定加载哪些属性，这样DTO生成器就只加载客户端指定的属性，其他属性不予以加载，这减小了网络流量。

l   屏蔽CGLib、Hibernate等的影响，客户端可以把DTO当成一个没有任何副作用的普通JavaBean使用。

l   允许客户端将修改后的DTO传递回服务器端进行更新。

采用简单的对象克隆方法无法得到满足要求的DTO， 因为克隆以后的对象仍然是和PO一样的被代理对象。更好的解决方法就是重新生成一个与PO的原有类型(比如PersonInfo，而非 PersonInfo$CGLib$Proxy)一致的JavaBean作为DTO，然后将客户端需要的PO中的属性赋值到DTO中。在复制过程中，因为 PO以及关联的对象的信息已经被LazyLoad破坏得乱七八糟了，所以我们必须要通过一种机制知道对象的字段有哪些、字段的类型是什么、字段是否是关联 对象、关联的类型是什么。了解这些信息的最好方式就是通过元数据，案例系统的元数据机制就可以满足这个要求，而且Hibernate也有元数据机制能提供 类似的信息

三.VO

一、PO:persistant object 持久对象,可以看成是与数据库中的表相映射的java对象。使用Hibernate来生成PO是不错的选择。

二、VO:value object值对象。通常用于业务层之间的数据传递，和PO一样也是仅仅包含数据而已。但应是抽象出的业务对象,可以和表对应,也可以不,这根据业务的需要.

有一种观点就是：PO只能用在数据层，VO用在商业逻辑层和表示层。各层操作属于该层自己的数据对象，这样就可以降低各层之间的耦合，便于以后系统的维护和扩展。如果将PO用在各个层中就相当于我们使用全局变量，我们知道在OO设计非常不赞成使用全局变量。

但是每次都得进行VO-PO的转换，也确实很烦。我觉得有时候也可以在某个商业逻辑或者表示层使用PO，此时在这个商业逻辑的过程中PO的状态是不发生变化的，比如显示一条商品详细信息的商业逻辑。

在开发过的项目中，规模都很小，我一直都把PO当VO用，因为PO确实很方便，结合Hibernate的DAO，我使用JAVA的集合对象作为值传递的载体，当然Struts也是我的不二之选。