`
lvinie
  • 浏览: 110942 次
  • 性别: Icon_minigender_1
  • 来自: 郑州
社区版块
存档分类
最新评论

PO VO FormBean

    博客分类:
  • java
阅读更多

概念:

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

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics