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对象维护开销。

评论

1 楼 gatusso52 2009-03-05  

另有一篇文章


那么在一个完整的J2EE系统中应该如何进行合理的设计呢？

1   JSP(View) ---> ActionFormBean(Module) ---> Action(Control)

ActionFormBean是Web层的数据表示，它和HTML页面Form对应，只要Web页面的操作流程发生改变，它就要相应的进行修改，它不应该也不能被传递到业务层和持久层，否则一旦页面修改，会一直牵连到业务层和持久层的大面积的代码进行修改，对于软件的可维护性和可扩展性而言，是一个灾难，Action就是他的边界，到此为止！

2   Action(Web Control) ---> Business Bean ---> DAO ---> ORM --->DB

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


我的理解：
1 2 这个流程很经典，学习
不过没有说PO与VO的区别