现在流行的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出来的,没有状态),显示提交。