`
凤舞凰扬
  • 浏览: 65417 次
  • 性别: Icon_minigender_1
  • 来自: 杭州
社区版块
存档分类
最新评论

VO , 我们不需要么?

    博客分类:
  • Java
阅读更多
这两天,在视线论坛就VO与PO的问题发了很多帖子,也看了一些网友的BLOG,围绕这个问题,大家你来我往了许久,许多的程序员或者设计人员,最擅长的是问这样做有什么好处,最喜欢的是反对是提出疑义,而不是去理解为什么要这样,原因是什么?所以兴致来了,就记录一下自己的感受和心态。
   DTO,一个衍生于VO的副产品,一个来自J2EE核心模式的一部分。其实它更多的只是描述了VO中的一部分职能:数据传输。它出现的目的是为了降低对数据存储的访问。如果单纯从DTO的角度去探讨其与PO的关系和作用,倒是仁者见仁,智者见智了。
   我想说的,是VO ,除了DTO描述的一部分外,它更为重要地是反映业务实体,反映客户(交互的人或者系统)所需要看到的对象。正因为在设计上业务实体与物理实体的分离,也就自然导致了VO与PO是两个完全不同的概念。很多网友都喜欢拘泥于他们中涵盖了似乎相同的字段,而这又能说明什么呢?(因为从理论上讲,PO与VO的字段是完全可以不同的)。我们讨论架构中多层的应用的时候,是怎么区分各层的呢?其实框架间和层之间的隔离是依靠两种:功能接口与通信介质。VO就是业务层与相邻各层的通信介质及数据表现介质。正因为有了VO的出现,就将业务实体的反映与界面表现的反映以及物理存储实体的反映隔离开来,也就真正实现了层的概念。否则,一通到底,还叫什么多层应用?(当然,那也许是一个好的web应用,但绝对称不上是一个多层架构应用的)。业务实体和物理实体间的关系是不确定的,业务实体取决于客观的业务情况,而物理实体就是取决与设计人员了。一个业务实体也许只是一个物理实体的部分(比如说我们看到一个人的简介的时候,是不包括人的全部信息的),一个业务实体也许和一个物理实体相同(比如说,一个人员信息的业务表现和物理表现一般都是相同的),一个业务实体也许包含(准确地讲应该是来自于)多个物理实体(比如说,一个订单,包括货币,客户,物品等各种各样的实体信息)。更为简单地讲,就是客户需要看到汽车(业务实体),而不需要了解汽车中的零配件(物理实体)是来自于何处。
    这样说来,VO的好处和作用已经相当明显了,它根本就不是PO所能代替和作用的(表面上看它起了简化的作用,实质上增加了系统间的耦合性,除非,作者对这种耦合性闭而不见),那么,VO,我们不需要么?
    采用多层的架构,我们必然会失去一些东西,如果这些东西不值得(比如就像某些文章说的“永远”不会存在什么分布式的时候),那么盲目地使用这样的架构是不太可取的;但是,如果在构建一个大型,稳健,具有高度扩展性的系统的时候,失去一些东西是需要的(比如说对象间相互数据转换的代销)。
分享到:
评论
3 楼 zhangskills 2010-03-03  
正在学习Java,对分层传值的概念有太多的疑惑和不懂,看了你下凰兄当年的回复的那个论坛,默默地从04年5月读到06年8月,真的觉得很有帮助。佩服你的雅量,也佩服你的高谈,呵呵
2 楼 czwlucky 2008-01-10  
我曾经在不了解这些概念之前就已经用到VO了,不过后来发现这样也挺麻烦的。我一直用DWR做开发,放多工作可以放到客户端来做,比如:一个人的信息,包括基本信息,部门相关信息等,这是两种信息的组合才能形成的,我可以组装好一个完整的信息给客户端发过去,也可以将他们一股脑的发过去,组装?到页面上去做吧!
现在看到这些东西,我才发觉,我开始担心啦,会不会以后出现大麻烦呀?这样做安不安全呀?请赐教!谢谢!czwlucky@163.com
1 楼 lovevirus 2006-10-06  
很有启发,我对vo的感觉和你一样,不过在简单的项目中是一个累赘,但是我一直用着他,因为我觉得如果业务复杂了,对vo越来越重要,基本上是业务的逻辑

相关推荐

Global site tag (gtag.js) - Google Analytics