VO and PO

    VO(value object) 值对象 通常用于业务层之间的数据传递，和PO一样也是仅仅包含数据而已。但应是抽象出的业务对象,可以和表对应,也可以不,这根据业务的需要.个人觉得同DTO(数据传输对象),在web上传递。    BO(business object) 业务对象 从业务模型的角度看,见UML元件领域模型中的领域对象。封装业务逻辑的java对象,通过调用DAO方法,结合PO,VO进行业务操作。        PO(persistant object) 持久对象 在o/r映射的时候出现的概念，如果没有o/r映射，没有这个概念存在了。通常对应数据模型(数据库),本身还有部分业务逻辑的处理。可以看成是与数据库中的表相映射的java对象。最简单的PO就是对应数据库中某个表中的一条记录，多个记录可以用PO的集合。PO中应该不包含任何对数据库的操作。
 
    由Hibernate VO和Hibernate PO的概念，又引申出一些系统层次设计方面的问题。如在传统的MVC架构中，位于Model层的PO，是否允许被传递到其他层面。
由于PO的更新最终将被映射到实际数据库中，如果PO在其他层面（如View层）发生了变动，那么可能会对Model 层造成意想不到的破坏。
    因此，一般而言，应该避免直接PO传递到系统中的其他层面，一种解决办法是，通过一个VO，通过属性复制使其具备与PO相同属性值，
并以其为传输媒质（实际上，这个VO被用作Data Transfer Object，即所谓的DTO），将此VO传递给其他层面以实现必须的数据传送。
VO经过Hibernate进行处理，就变成了PO。

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