上一篇 文章作为一个引子,说明了领域驱动设计的优势,从本篇文章开始,笔者将会结合自己的实际经验,谈及领域驱动设计的应用。本篇文章主要讨论一下我们经常会用到的一些对象:VO、DTO、DO 和 PO。
由于不同的项目和开发人员有不同的命名习惯,这里我首先对上述的概念进行一个简单描述,名字只是个标识,我们重点关注其概念:
概念:
VO(View Object):视图对象,用于展示层,它的作用是把某个指定页面(或组件)的所有数据封装起来。
DTO(Data Transfer Object):数据传输对象,这个概念来源于 J2EE 的设计模式,原来的目的是为了 EJB 的分布式应用提供粗粒度的数据实体,以减少分布式调用的次数,从而提高分布式调用的性能和降低网络负载,但在这里,我泛指用于展示层与服务层之间的数据传输对象。
DO(Domain Object):领域对象,就是从现实世界中抽象出来的有形或无形的业务实体。
PO(Persistent Object):持久化对象,它跟持久层(通常是关系型数据库)的数据结构形成一一对应的映射关系,如果持久层是关系型数据库,那么,数据表中的每个字段(或若干个)就对应 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 并存:
DTO 与 DO 的区别
首先是概念上的区别,DTO 是展示层和服务层之间的数据传输对象(可以认为是两者之间的协议),而 DO 是对现实世界各种业务角色的抽象,这就引出了两者在数据上的区别,例如 UserInfo 和 User(对于 DTO 和 DO 的命名规则,请参见笔者前面的 一篇博文 ),对于一个 getUser 方法来说,本质上它永远不应该返回用户的密码,因此 UserInfo 至少比 User 少一个 password 的数据。而在领域驱动设计中,正如 第一篇 系列文章所说,DO 不是简单的 POJO,它具有领域业务逻辑。
DTO 与 DO 的应用
从上一节的例子中,细心的读者可能会发现问题:既然 getUser 方法返回的 UserInfo 不应该包含 password,那么就不应该存在 password 这个属性定义,但如果同时有一个 createUser 的方法,传入的 UserInfo 需要包含用户的 password,怎么办?在设计层面,展示层向服务层传递的 DTO 与服务层返回给展示层的 DTO 在概念上是不同的,但在实现层面,我们通常很少会这样做(定义两个 UserInfo,甚至更多),因为这样做并不见得很明智,我们完全可以设计一个完全兼容的 DTO,在服务层接收数据的时候,不该由展示层设置的属性(如订单的总价应该由其单价、数量、折扣等决定),无论展示层是否设置,服务层都一概忽略,而在服务层返回数据时,不该返回的数据(如用户密码),就不设置对应的属性。
对于 DO 来说,还有一点需要说明:为什么不在服务层中直接返回 DO 呢?这样可以省去 DTO 的编码和转换工作,原因如下:
对于 DTO 来说,也有一点必须进行说明,就是 DTO 应该是一个 "扁平的二维对象",举个例子来说明:如果 User 会关联若干个其他实体(例如 Address、Account、Region 等),那么 getUser() 返回的 UserInfo,是否就需要把其关联的对象的 DTO 都一并返回呢?如果这样的话,必然导致数据传输量的大增,对于分布式应用来说,由于涉及数据在网络上的传输、序列化和反序列化,这种设计更不可接受。如果 getUser 除了要返回 User 的基本信息外,还需要返回一个 AccountId、AccountName、RegionId、RegionName,那么,请把这些属性定义到 UserInfo 中,把一个" 立体 "的对象树" 压扁 "成一个" 扁平的二维对象 "。笔者目前参与的项目是一个分布式系统,该系统不管三七二十一,把一个对象的所有关联对象都转换为相同结构的 DTO 对象树并返回,导致性能非常的慢。
DO 与 PO 的区别
DO 和 PO 在绝大部分情况下是一一对应的,PO 是只含有 get/set 方法的 POJO,但某些场景还是能反映出两者在概念上存在本质的区别:
DO 与 PO 的应用
由于 ORM 框架的功能非常强大而大行其道,而且 JavaEE 也推出了 JPA 规范,现在的业务应用开发,基本上不需要区分 DO 与 PO,PO 完全可以通过 JPA,Hibernate Annotations/hbm 隐藏在 DO 之中。虽然如此,但有些问题我们还必须注意:
到目前为止,相信大家都已经比较清晰的了解 VO、DTO、DO、PO 的概念、区别和实际应用了。通过上面的详细分析,我们还可以总结出一个原则:分析设计层面和实现层面完全是两个独立的层面,即使实现层面通过某种技术手段可以把两个完全独立的概念合二为一,在分析设计层面,我们仍然(至少在头脑中)需要把概念上独立的东西清晰的区分开来,这个原则对于做好分析设计非常重要(工具越先进,往往会让我们越麻木)。 第一篇 系列博文抛砖引玉,大唱领域驱动设计的优势,但其实领域驱动设计在现实环境中还是有种种的限制,需要选择性的使用,正如我在《 田七的智慧 》博文中提到,我们不能永远的理想化的去选择所谓 "最好的设计",在必要的情况下,我们还是要敢于放弃,因为最合适的设计才是最好的设计。本来,系列中的第二篇博文应该是讨论领取驱动设计的限制和如何选择性的使用,但请原谅我的疏忽, 下一篇 系列博文会把这个主题补上,敬请关注。
来源: http://www.bubuko.com/infodetail-2450933.html