分层体系之VO与PO

现在流行的web框架多如牛毛，随之而来的讨论也是与日俱增。说说 我们项目采用的架构[Struts + Spring + Hibernate ](目前很流行的一种架构选择)，之前在网上有些人讨论，关于VO 与 PO 的问题(也许你们的名字有些不同，但意思一样)，

这里所谓的VO:指用于表现层的相对于PO的数据传输对象

这里所谓的PO:指用于持久层的，和数据库对应的数据传说对象。

 

我在之前写过一篇"DTO模型带来的好处"文章，其中就介绍了，我们在写程序的时候应该分层，毕竟我们的目标就是低耦合高内聚呀。然后在不同的架构中，他更有不同的需要，在应用hibernate的项目中，对于vo和po是不是可以以一个对象的身份取代2者的回答是，不可以，绝对不可以。为什么这样说呢，因为，Hibernate有它自己的持久层用法；

有状态的javabean,也就是这个对象在hibernate自己的session已被记录

比如说

GradeChangePO po = (GradeChangePO)getObject(GradeChangePO.class,oid);

我们通过这中或是其他方式从数据库中，获得一个持久层对象，表面看起来就是一个javabean，但其实，它是有状态的，这一点很重要，如果在代码中，因为某些需要，改变了po的属性值，比如 po.setName("test");   那么即使就这样结束了这个方法，那么它也会自动更新该po所对应数据库记录。甚至不需要我们显示调用saveOrUpdateObject(po);就可以更新。如果你用的从数据库中获取的po，然后po.setOid(....);如果我们在调用 gradeChangeDAO.deleteObject(poObject);时就会提示你正在删除session中已存在的对象具有不同oid对象异常。

 

所以，这种情况下，分层更加重要，通常的是

action 层 /service 层 / dao层  ； 我要应该把和数据库的交互以都放在dao中，把一些业务及逻辑上的处理放在service中，

至于po或vo的装换 如果其他的地方也需要最好单独封装一个转换类，如果其他地方不需要，在dao中写一个回调方法或内部私有类也不错。

这样我们业务操作的总是vo，不会影响到po，然后再需要提交数据时将其转换为po(这个po通常是new出来的，没有状态)，显示提交。