使用Hibernate的项目中对VO的理解
前段时间我参与了使用Struts,ibernate的项目,如今项目已经结束,对多层系统的设计有了一些理解.这个项目主要的实现思想和这篇文章---结合struts和hibernate谈J2EE架构的数据表示, 讲述的是一致的.大家可以先浏览一下,我主要想和大家讨论一下VO.
Web层的数据表示是FormBean,数据来源于HTML Form POST
业务层的数据表示是VO
持久层的数据表示是PO,其数据来源于数据库,持久层的数据表示例如CMP
一般系统的结构是这样的, Action(Web Control) ---> Business Bean ---> DAO ---> ORM --->DB ,可以看出VO的作用就是把数据从Dao层传递到Action中,或者Action传递到Dao中, 其实就是 FormBean ---> VO---> PO,或者PO---->VO---->FormBean. 当然就想Robbin说的那样,好多的系统喜欢省掉VO,直接让PO传递到FormBean,或者在Action中new一个PO,把PO传递到DAO中,这样也是可以的, 主要也就是因为Hibernate功能强大,PO能脱离持久层,像JDO之类的就不可以了,所以在规划系统的时候,必须考虑一个情况是,你的系统以后在维护的时候,是否可能更改持久层产品, 如果可能VO 还是需要的,不然你会修改会很痛苦.
当然省掉VO确实很爽,我们的系统就是这样的,比较方便,不用再去维护一个VO,效率上当然有不小的提高,但是还有个要注意的问题就是数据库的设计, 一般来说在面向对象编程中,数据库应该使用面向对象的思想设计, 但是这个好多的系统设计是做不到的,或者是老系统没法改变. 存在的问题就是表的设计不合理, 就会出现表的字段很多,当然对应的PO也就会很大,但有时有些信息并不是表示层所需要的也会传递过去,效率上肯定是受损失的,所以这个时候可以使用VO, VO的大小当然可以按照实际的需要定制,特别是在查询的数据很多的时候,对效率有一定的提高的.
Web层的数据表示是FormBean,数据来源于HTML Form POST
业务层的数据表示是VO
持久层的数据表示是PO,其数据来源于数据库,持久层的数据表示例如CMP
一般系统的结构是这样的, Action(Web Control) ---> Business Bean ---> DAO ---> ORM --->DB ,可以看出VO的作用就是把数据从Dao层传递到Action中,或者Action传递到Dao中, 其实就是 FormBean ---> VO---> PO,或者PO---->VO---->FormBean. 当然就想Robbin说的那样,好多的系统喜欢省掉VO,直接让PO传递到FormBean,或者在Action中new一个PO,把PO传递到DAO中,这样也是可以的, 主要也就是因为Hibernate功能强大,PO能脱离持久层,像JDO之类的就不可以了,所以在规划系统的时候,必须考虑一个情况是,你的系统以后在维护的时候,是否可能更改持久层产品, 如果可能VO 还是需要的,不然你会修改会很痛苦.
当然省掉VO确实很爽,我们的系统就是这样的,比较方便,不用再去维护一个VO,效率上当然有不小的提高,但是还有个要注意的问题就是数据库的设计, 一般来说在面向对象编程中,数据库应该使用面向对象的思想设计, 但是这个好多的系统设计是做不到的,或者是老系统没法改变. 存在的问题就是表的设计不合理, 就会出现表的字段很多,当然对应的PO也就会很大,但有时有些信息并不是表示层所需要的也会传递过去,效率上肯定是受损失的,所以这个时候可以使用VO, VO的大小当然可以按照实际的需要定制,特别是在查询的数据很多的时候,对效率有一定的提高的.
这是我的一点小的体会,希望大家多多讨论.