我对VO和pojo还是理解不透 先解释一下我认为的vo 和 pojo吧
假设一个项目 使用struts+hibernate
那么在项目下有2个类
cn.vo.UserList
这个类 是VO 用来在BO里面和向页面传递数据使用
cn.hib.pojo.UserList
这个主要是和数据库传递数据
我想问 很多人都是把pojo和vo分开 我对此有点不理解
但是里面的属性基本的都差不多的 都基本对应数据库某表的字段
为什么不直接用pojo来传值呢?
要是分开的话 多写一个类不说
而且每次都要转换
比如
这样我觉得代码很繁琐 自己也感觉不到这样做的好处
难道只用一个pojo来传递数据不好吗?
1.VO是用new关键字创建,由GC回收的。
PO是向数据库中添加新数据时创建,删除数据库中数据时删除的。
并且它只能存活在一个数据库连接中,当连接断开时,将被销毁。
2.VO是值对象,精确点讲它是业务对象,是存活在业务层的,是业务
逻辑使用的,它存活的目的就是为数据提供一个生存的地方。
PO是有状态的,每个属性代表其当前的状态。它是物理数据的对象
表示。使用它,可以使我们的程序与物理数据解耦,并且可以简化
对象数据与物理数据之间的转换。
3.VO的属性是根据当前业务的不同而不同的,也就是说,它的每一个
属性都一一对应当前业务逻辑所需要的数据的名称。
PO的属性是跟数据库表的字段一一对应的。
4.VO是独立的Java Object。
PO是由Hibernate纳入其实体容器(Entity Map)的对象,它代表了
与数据库中某条记录对应的Hibernate实体,PO的变化在事务提交时
将反应到实际数据库中。
不用po代替vo的主要原因还有
业务层的方法的参数和返回类型不能是POJO,因为当POJO处于持久化状态时,会同步更新数据库,会带来一定的危险性,即在用户不知觉的情况下会对数据进行修改,所以,不能在控制器中对POJO进行操作,而用VO代替。使用VO可以避免Session已关闭的异常。
假设一个项目 使用struts+hibernate
那么在项目下有2个类
cn.vo.UserList
这个类 是VO 用来在BO里面和向页面传递数据使用
cn.hib.pojo.UserList
这个主要是和数据库传递数据
我想问 很多人都是把pojo和vo分开 我对此有点不理解
但是里面的属性基本的都差不多的 都基本对应数据库某表的字段
为什么不直接用pojo来传值呢?
要是分开的话 多写一个类不说
而且每次都要转换
比如
cn.hib.pojo.UserList user = (cn.hib.pojo.UserList)session.get(cn.hib.pojo.UserList.class,1);
//这里获得pojo
cn.vo.UserList vuser = new cn.vo.UserList();
//创建一个vo对象实例
BeanUtils.copyProperties(vuser,user);
//使用BeanUtils转换
这样我觉得代码很繁琐 自己也感觉不到这样做的好处
难道只用一个pojo来传递数据不好吗?
大家能谈谈在实际开发中是怎么做的 谢谢.
----------------------------------------------------------------------------------------------------------------------------------------
1.VO是用new关键字创建,由GC回收的。
PO是向数据库中添加新数据时创建,删除数据库中数据时删除的。
并且它只能存活在一个数据库连接中,当连接断开时,将被销毁。
2.VO是值对象,精确点讲它是业务对象,是存活在业务层的,是业务
逻辑使用的,它存活的目的就是为数据提供一个生存的地方。
PO是有状态的,每个属性代表其当前的状态。它是物理数据的对象
表示。使用它,可以使我们的程序与物理数据解耦,并且可以简化
对象数据与物理数据之间的转换。
3.VO的属性是根据当前业务的不同而不同的,也就是说,它的每一个
属性都一一对应当前业务逻辑所需要的数据的名称。
PO的属性是跟数据库表的字段一一对应的。
4.VO是独立的Java Object。
PO是由Hibernate纳入其实体容器(Entity Map)的对象,它代表了
与数据库中某条记录对应的Hibernate实体,PO的变化在事务提交时
将反应到实际数据库中。
不用po代替vo的主要原因还有
业务层的方法的参数和返回类型不能是POJO,因为当POJO处于持久化状态时,会同步更新数据库,会带来一定的危险性,即在用户不知觉的情况下会对数据进行修改,所以,不能在控制器中对POJO进行操作,而用VO代替。使用VO可以避免Session已关闭的异常。