posts - 16,comments - 17,trackbacks - 0
    网上一大堆关于PO,POJO,DTO,VO等等对象的讨论,通常都是各持己见,公说公有理,婆说婆有理,讨论到最后也没有什么定论。今天看到一个应用的代码,发现其讲PO直接做为VO(view object)在表示层使用。只从代码上讲,这样做确实省去了跟多操作。不用重复的做对象的赋值、构造。但是会过头来看,这样无疑增加了代码的耦合性。做一个简单的假设,如果对持久层的PO进行了修改,相应的使用PO做为对应的VO(value object)业务逻辑层和使用PO最为VO(view object)的表示层都必须做相应的修改,如此的应用给代码的维护带来了很大的负担,可谓是一动则百动。
    在J2EE应用开发中,是不应该出现这中PO共享使用的方式的。实体对象不应该被跨层使用,各层维护自己的实体对象。这点看书我想大家都知道,而在实际应用中很多人都选择不遵循这一规则。(在使用hibernate时有所不同,引用:“不过由于Hibernate的强大功能,例如动态生成PO,PO的状态管理可以脱离Session,使得在应用了Hibernate的J2EE框架中,PO完全可以充当VO,因此我们下面把PO和VO合并,统称为PO。”引文:结合struts和hibernate谈J2EE架构的数据表示。)出现这总现象,我想原因只有一个就是贪图了一时的省事,在一次性应用开发中,相对的业务对象改动可能性相当的少,很多时候在做项目的时候并不会出现预料不到的改变,没有必要去管理一大堆各式各样的实体对象,这样就自然的导致了PO在各层中共享使用。可是就我目前接触到的项目基本上没有需求是如此明确的,通常需求都是在不断的改变,甚至有时到了最后发版的时候,一些客户都会提出修改需求的要求。另外就是自做需求的情况就更是如此了,这种项目的需求是不断的在变化的。为了保证项目的适应性和可扩展性,就必须保证各层之间的相对独立,尽可能降低耦合度。



posted on 2005-03-01 12:40 非飞 阅读(2426) 评论(2)  编辑  收藏

FeedBack:
# re: 各层共享使用PO的代价
2006-03-24 16:22 | TMD
都TMD的人云亦云,很少有说PO变动之后,VO不变动的,既然两个都要动,何不只动一个?  回复  更多评论
  
# re: 各层共享使用PO的代价
2006-10-05 23:28 | CowNew开源团队
我的观点,大部分实体对象只要vo、po重用就可以了,只有vo、po差距较大的地方才分开,这样就做到了简洁性和可扩展性的良好折中。  回复  更多评论
  

只有注册用户登录后才能发表评论。


网站导航: