浅析VO、DTO、DO、PO的概念、区别和用处.docxVIP

浅析VO、DTO、DO、PO的概念、区分和用处 Java后端架构 2021-03-08 由于不同的项目和开发人员有不同的命名习惯，这里我首先对上述的概念进行一个简约描述，名字只是个标识，我们重点关注其概念： ? 概念： VO（View Object）：视图对象，用于呈现层，它的作用是把某个指定页面（或组件）的全部数据封装起来。 DTO（Data Transfer Object）：数据传输对象，这个概念来源于J2EE的设计模式，原来的目的是为了EJB的分布式应用供应粗粒度的数据实体，以削减分布式调用的次数，从而提高分布式调用的功能和降低网络负载，但在这里，我泛指用于呈现层与服务层之间的数据传输对象。 DO（Domain Object）：领域对象，就是从现实世界中笼统出来的无形或无形的业务实体。 PO（Persistent Object）：长久化对象，它跟长久层（通常是关系型数据库）的数据结构构成逐一对应的映射关系，假如长久层是关系型数据库，那么，数据表中的每个字段（或若干个）就对应PO的一个（或若干个）属性。 ? 模型： ? ? ? ?下面以一个时序图建立简约模型来描述上述对象在三层架构应用中的位置 ? ? ? ? ? ????? ? ? ? ??用户发出恳求（可能是填写表单），表单的数据在呈现层被婚配为VO。 ? ? ? ? ?呈现层把VO转换为服务层对应方法所要求的DTO，传送给服务层。 ? ? ? ? ?服务层首先依据DTO的数据构造（或重建）一个DO，调用DO的业务方法完成具体业务。 ? ? ? ? ?服务层把DO转换为长久层对应的PO（可以使用ORM工具，也可以不用），调用长久层的长久化方法，把PO传递给它，完成长久化操作。 ? ? ? ? ?对于一个逆向操作，如读取数据，也是用类似的方式转换和传递，略。 ? VO与DTO的区分 ? ? ? ?大家可能会有个疑问（在笔者参与的项目中，很多程序员也有相同的怀疑）：既然DTO是呈现层与服务层之间传递数据的对象，为什么还需要一个VO呢？对！对于绝大部分的应用场景来说，DTO和VO的属性值基本是全都的，而且他们通常都是POJO，因而没必要多此一举，但不要遗忘这是实现层面的思维，对于设计层面来说，概念上还是应当存在VO和DTO，由于两者有着本质的区分，DTO代表服务层需要接收的数据和前往的数据，而VO代表呈现层需要显示的数据。 ? ? ? ?用一个例子来说明可能会比较简约理解：例如服务层有一个getUser的方法前往一个系统用户，其中有一个属性是gender(性别)，对于服务层来说，它只从语义上定义：1-男性，2-女性，0-未指定，而对于呈现层来说，它可能需要用“帅哥”代表男性，用“美女”代表女性，用“隐秘”代表未指定。说到这里，可能你还会反对，在服务层直接就前往“帅哥美女”不就行了吗？对于大部分应用来说，这不是问题，但设想一下，假如需求允许客户可以定制风格，而不同风格对于“性别”的表现方式不一样，又或者这个服务同时供多个客户端使用（不同门户），而不同的客户端对于表现层的要求有所不同，那么，问题就来了。再者，回到设计层面上分析，从职责单一准绳来看，服务层只担任业务，与具体的表现方式无关，因而，它前往的DTO，不应当消灭与表现方式的耦合。 ? ? ? ?理论归理论，这到底还是分析设计层面的思维，能否在实现层面必需这样做呢？一刀切的做法往往会得不偿失，下面我马上会分析应用中如何做出正确的选择。 ? VO与DTO的应用 ? ? ? ?上面只是用了一个简约的例子来说明VO与DTO在概念上的区分，本节将会告知你如何在应用中做出正确的选择。 ? ? ? ?在以下才场景中，我们可以考虑把VO与DTO二合为一（留意：是实现层面）： ? ? ? ? ?当需求格外清楚稳定，而且客户端很明确只要一个的时候，没有必要把VO和DTO区分开来，这时候VO可以退隐，用一个DTO即可，为什么是VO退隐而不是DTO？回到设计层面，服务层的职责照旧不应当与呈现层耦合，所以，对于前面的例子，你很简约理解，DTO对于“性别”来说，照旧不能用“帅哥美女”，这个转换应当依靠于页面的脚本（如JavaScript）或其他机制（JSTL、EL、CSS） ? ? ? ? ?即便客户端可以进行定制，或者存在多个不同的客户端，假如客户端能够用某种技术（脚本或其他机制）实现转换，同样可以让VO退隐 ? 以下场景需要优先考虑VO、DTO并存： ? ? ? ? ?上述场景的反面场景 ? ? ? ? ?由于某种技术缘由，比如某个框架（如Flex）供应自动把POJO转换为UI中某些Field时，可以考虑在实现层面定义出VO，这个权衡完全取决于使用框架的自动转换力量带来的开发和维护效率提升与设计多一个VO所多做的事情带来的开发和维护