二、VO:value object值对象。通常用于业务层之间的数据传递，和PO一样也是仅仅包含数据而已。但应是抽象出的业务对象,可以和表对应,也可以不,这根据业务的需要.
PO只能用在数据层，VO用在商业逻辑层和表示层。各层操作属于该层自己的数据对象，这样就可以降低各层之间的耦合，便于以后系统的维护和扩展。
持久对象,可以看成是2113与数据库中5261的表相映射的java对象。使用4102hibernate来生成po是不错的选择。
object值对象。通常用1653于业务层之间的数据传递，和po一样也是仅仅包含数据而已。但应是抽象出的业务对象,可以和表对应,也可以不,这根据业务的需要.
有一种观点就是：po只能用在数据层，vo用在商业逻辑层和表示层。各层操作属于该层自己的数据对象，这样就可以降低各层之间的耦合，便于以后系统的维护和扩展。如果将po用在各个层中就相当于我们使用全局变量，我们知道在oo设计非常不赞成使用全局变量。
但是每次都得进行vo-po的转换，也确实很烦。我觉得有时候也可以在某个商业逻辑或者表示层使用po，此时在这个商业逻辑的过程中po的状态是不发生变化的，比如显示一条商品详细信息的商业逻辑。
在开发过的项目中，规模都很小，我一直都把po当vo用，因为po确实很方便，结合hibernate的dao，我使用java的集合对象作为值传递的载体，当然struts也是我的不二之选。
我认为：在一些直观的，简单的，不易发生变化的，不需要涉及多个po时，传递值还是使用po好，这样可以减少大量的工作量（也就意味着减少bug，减少风险），也不需要担心未来的维护工作!
VO它是在hibernate中提出来的,VO的意思就是瞬时太的意思，如果想了解详细的介绍，请察看hibernate；
