关闭

分层体系之VO与PO

3213人阅读 评论(2) 收藏 举报

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

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

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

 

我在之前写过一篇"DTO模型带来的好处"文章,其中就介绍了,我们在写程序的时候应该分层,毕竟我们的目标就是低耦合高内聚呀。然后在不同的架构中,他更有不同的需要,在应用hibernate的项目中,对于vopo是不是可以以一个对象的身份取代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中,

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

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


0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:170979次
    • 积分:2354
    • 等级:
    • 排名:第15889名
    • 原创:54篇
    • 转载:2篇
    • 译文:1篇
    • 评论:49条
    最新评论