zoukankan      html  css  js  c++  java
  • 浅析VO、DTO、DO、PO的概念、区别和用处

    转载:
    https://www.cnblogs.com/qixuejia/p/4390086.html
    https://mp.weixin.qq.com/s/4EfuvEfkvXlJpzXCzXwo8Q

    PO

    PO:持久化对象,它跟持久层(通常是关系型数据库)的数据结构形成一一对应的映射关系,如果持久层是关系型数据库,那么,数据表中的每个字段就对应PO的每个属性。





    VO

    VO:视图对象,用于展示层,它的作用是把某个指定页面(或组件)的所有数据封装起来。
    举个例:页面上有个表单,我们需要将这个表单的数据提交,那么我们就可以创建一个VO来接收。同样的现在页面上有个列表数据,我们也可以创建一个VO来接收数据返回给页面。





    DTO

    DTO:数据传输对象,用于展示层与服务层之间的数据传输对象。
    举个例:
    表里面有十几个字段:id,name,gender,age,address,conmpanyId。
    页面需要展示四个字段:name,gender,age,conmpanyName。
    DTO由此产生,一是能提高数据传输的速度(减少了传输字段),二能隐藏后端表结构。

    注意:DTO并不返回给前端,与前端打交道的是VO,所以我们应该将其变成VO再返回给前端。

    VO与DTO的区别
    
           大家可能会有个疑问(在笔者参与的项目中,很多程序员也有相同的疑惑):既然DTO是展示层与服务层之间传递数据的对象,为什么还需要一个VO呢?对!对于绝大部分的应用场景来说,DTO和VO的属性值基本是一致的,而且他们通常都是POJO,因此没必要多此一举,但不要忘记这是实现层面的思维,对于设计层面来说,概念上还是应该存在VO和DTO,因为两者有着本质的区别,DTO代表服务层需要接收的数据和返回的数据,而VO代表展示层需要显示的数据。
    
           用一个例子来说明可能会比较容易理解:例如服务层有一个getUser的方法返回一个系统用户,其中有一个属性是gender(性别),对于服务层来说,它只从语义上定义:1-男性,2-女性,0-未指定,而对于展示层来说,它可能需要用“帅哥”代表男性,用“美女”代表女性,用“秘密”代表未指定。说到这里,可能你还会反驳,在服务层直接就返回“帅哥美女”不就行了吗?对于大部分应用来说,这不是问题,但设想一下,如果需求允许客户可以定制风格,而不同风格对于“性别”的表现方式不一样,又或者这个服务同时供多个客户端使用(不同门户),而不同的客户端对于表现层的要求有所不同,那么,问题就来了。再者,回到设计层面上分析,从职责单一原则来看,服务层只负责业务,与具体的表现形式无关,因此,它返回的DTO,不应该出现与表现形式的耦合。
    
           理论归理论,这到底还是分析设计层面的思维,是否在实现层面必须这样做呢?一刀切的做法往往会得不偿失,下面我马上会分析应用中如何做出正确的选择。
    
     
    
    VO与DTO的应用
    
           上面只是用了一个简单的例子来说明VO与DTO在概念上的区别,本节将会告诉你如何在应用中做出正确的选择。
    
           在以下才场景中,我们可以考虑把VO与DTO二合为一(注意:是实现层面):
    
    l         当需求非常清晰稳定,而且客户端很明确只有一个的时候,没有必要把VO和DTO区分开来,这时候VO可以退隐,用一个DTO即可,为什么是VO退隐而不是DTO?回到设计层面,服务层的职责依然不应该与展示层耦合,所以,对于前面的例子,你很容易理解,DTO对于“性别”来说,依然不能用“帅哥美女”,这个转换应该依赖于页面的脚本(如JavaScript)或其他机制(JSTL、EL、CSS)
    
    l         即使客户端可以进行定制,或者存在多个不同的客户端,如果客户端能够用某种技术(脚本或其他机制)实现转换,同样可以让VO退隐
    
     
    
    以下场景需要优先考虑VO、DTO并存:
    
    l         上述场景的反面场景
    
    l         因为某种技术原因,比如某个框架(如Flex)提供自动把POJO转换为UI中某些Field时,可以考虑在实现层面定义出VO,这个权衡完全取决于使用框架的自动转换能力带来的开发和维护效率提升与设计多一个VO所多做的事情带来的开发和维护效率的下降之间的比对。
    
    l         如果页面出现一个“大视图”,而组成这个大视图的所有数据需要调用多个服务,返回多个DTO来组装(当然,这同样可以通过服务层提供一次性返回一个大视图的DTO来取代,但在服务层提供一个这样的方法是否合适,需要在设计层面进行权衡)。
    



    BO

    BO:业务对象,把业务逻辑封装为一个对象。
    我理解是 PO 的组合,比如投保人是一个 PO,被保险人是一个 PO,险种信息是一个 PO 等等,他们组合起来是第一张保单的 BO。





    POJO

    POJO:简单无规则 java 对象。
    纯的传统意义的 java 对象,最基本的 Java Bean 只有属性加上属性的 get 和 set 方法。可以转化为 PO、DTO、VO;比如 POJO 在传输过程中就是 DTO。

    总结


    为什么有这张图,因为在软件工程领域【哎呀,反正就是最最最最最标准的开发就是这样的】。
    实际开发,一般没有分的这么细。一般公司就只有 POJO,DTO,VO

  • 相关阅读:
    deepsort+yolov3实现多类别多目标跟踪
    WAR2020暑期补题集
    【数据结构】浅谈主席树
    Github本地上传命令
    【蓝桥杯】2017年第八届蓝桥杯C/C++B组省赛——C题 承压计算
    【蓝桥杯】2017年第八届蓝桥杯C/C++B组省赛——B题 等差素数列
    【蓝桥杯】2019年第十届蓝桥杯C/C++ B组省赛——I题 后缀表达式
    防御Mimikatz-转载
    SQL注入之判断数据库
    XPATH注入
  • 原文地址:https://www.cnblogs.com/itlihao/p/14824580.html
Copyright © 2011-2022 走看看