PO、VO、FormBean

概念：

PO是持久化对象 ，它只是将物理数据实体的一种对象表示，为什么需要它？因为它可以简化我们对于物理实体的了解和耦合，简单地讲，可以简化对象的数据转换为物理数据的编程 。

VO 是什么？它是值对象，准确地讲，它是业务对象 ，是生活在业务层的，是业务逻辑需要了解，需要使用的，再简单地讲，它是概念模型转换得到的。

FormBean 又是什么？它只是HTML表单的封装 ，是为了在控制层弱化request中存储数据的作用，将request的get方法转变为对象的存取值。

VO与PO的比较：
VO是业务对象 ，由业务逻辑使用，它存活的目的就是为数据提供一个生存的地方。
PO 则是数据对象的表现，它可以简化对象数据与物理数据的转换 。

VO由new关键字创建，由GC回收。
PO则是向数据库中添加新数据时创建，删除数据库中数据时删除，并且它只能存活在一个数据库连接中，断开连接即被销毁。

VO的属性根据当前的业务不同而不同。
PO的属性则是跟数据库表的字段一一对应。PO对象需要实现序列化接口。

 

PO与VO的关系：

首先说PO和VO吧，它们的关系应该是相互独立的，一个VO可以只是PO的部分，也可以是多个PO构成，同样也可以等同于一个PO（当然我是指他们的属性）。正因为这样，PO独立出来，数据持久层也就独立出来了，它不会受到任何业务的干涉。又正因为这样，业务逻辑层也独立开来，它不会受到数据持久层的影响，业务层关心的只是业务逻辑的处理，至于怎么存怎么读交给别人吧！不过，另外一点，如果我们没有使用数据持久层，或者说没有使用hibernate，那么PO和VO也可以是同一个东西，虽然这并不好。

 

VO与FormBean的关系：
其次，让我们看看FormBean和VO，如果简单地讲，我们是可以不需要FormBean的，它只是struts带来的一部分，而VO是无论如何不能舍弃的。如果让FormBean直接到业务层（它本来应该生活在控制层），那么会带来什么？View和Model就出现了强耦合，如果想改一下view的表示，整个业务逻辑都得改，恐怖的事情啊！

我的理解：

       PO对物理数据封装，代管了数据库的操作

then

       PO与VO之间的映射

then

       VO是逻辑业务的数据

then

       VO与FormBean的映射

then

       FormBean面向view，封装了request

 

 

Hibernate中PO有三种状态：
1.未被持久化的VO，此时就是一个内存对象VO，由JVM管理生命周期。
2.已被持久化的PO，并且在Session生命周期内，此时映射数据库连接，由数据库管理生命周期。
3.曾被持久化过，但现在和Session已经托管（detached）了，以VO的身份在运行。它还可以进入另一个Session，继续PO状态管理。
需要注意的是， PO最好只在持久层使用，如果脱离持久层到处使用，会给Hibernate带来不小的PO对象维护开销。