PO VO

由 PO 、 VO 的概念，又引申出一些系统层次设计方面的问题。如在传统的 MVC 架构中，位于 Model 层的 PO ，是否允许被传递到其他层面。由于 PO 的更新最终将被映射到实际数据库中，如果 PO 在其他层面（如 View 层）发生了变动，那么可能会对 Model 层造成意想不到的破坏。

 

因此，一般而言，应该避免直接将 PO 传递到系统中的其他层面，一种解决办法是，通过构造一个新的 VO ，通过属性复制使其具备与 PO 相同的属性值，并以其为传输媒质（实际上，这个 VO 被用作 Data Transfer Object ，即所谓的 DTO ），将此 VO 传递给其他层面以实现必须的数据传送。

 

属性复制可以通过 Apache Jakarta Commons Beanutils （ http://jakarta.apache.org/commons/beanutils/ ）组件提供的属性批量复制功能，避免繁复的 get/set 操作。

 

 

看到这段，让我想起了 Struts 中的 Form 和 Bean ，以前一直很疑惑几乎差不多一样的 JavaBean 文件为什么要写两个，还使用 Beanutils 将属性拷来拷去。现在好像明白了， Bean 可以认为是 PO ， Form 可以认为是 VO 。

 

 

   一、PO:persistant object 持久对象,可以看成是与数据库中的表相映射的java对象。最简单的PO就是对应数据库中某个表中的一条记录，多个记录可以用PO的集合。PO中应该不包含任何对数据库的操作。

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

 

 

而PO则是业务层和持久层的数据表示，它在业务层和持久层之间进行流动，他不应该也不能被传递到Web层的View中去，而ActionServlet就是他的边界，到此为止！

 

business  bean说的是 里面放的业务逻辑方法,businessbean 就是service

dao里面放的是最小的数据操作

vo是个临时数据,他不是一个实体,vo是存取器\一个是存取业务逻辑所需要的数据
hibernate里的po分为几种状态 暂态\ 在内存和数据库里都有的状态\持久态 ,

service(或叫biz\businessbean)是一个是组织业务逻辑叫做业务逻辑层,

POVO以bean的方式放在bean包里