领域驱动设计系列(2)浅析VO、DTO、DO、PO的概念、区别和用处

  • 时间:
  • 浏览:0
  • 来源:万人炸金花APP_万人炸金花APP官网

  概念:

  在以下才场景中,亲戚亲戚大伙儿都能不能 考虑把VO与DTO二合为一(注意:是实现层面):

  DO和PO在绝大每项情況下是一一对应的,PO是只暗含get/set妙招的POJO,但过后 场景还是能反映出两者在概念上处在本质的区别:

  VO与DTO的应用

亲戚亲戚大伙儿千万并不陷入过度设计,大可并不为了设计而设计一定要在代码中区分各个对象。语句技术是为应用服务的。

  首先是概念上的区别,DTO是展示层和服务层之间的数据传输对象(都能不能 认为是两者之间的协议),而DO是对现实世界各种业务角色的抽象,这就引出了两者在数据上的区别,类事于UserInfo和User(对于DTO和DO的命名规则,请参见笔者前面的一篇博文),对于有有有另一一二个getUser妙招来说,本质上它永远不应该返回用户的密码,过后UserInfo相当于比User少有有有另一一二个password的数据。而在领域驱动设计中,正如第一篇系列文章所说,DO有的是简单的POJO,它具有领域业务逻辑。

PO:

persistant object持久对象

最形象的理解很多很多很多很多有有有另一一二个PO很多很多很多很多数据库中的每根记录。

  DTO(Data Transfer Object):数据传输对象,這個 概念来源于J2EE的设计模式,很多很多很多很多的目的是为了EJB的分布式应用提供粗粒度的数据实体,以减少分布式调用的次数,从而提高分布式调用的性能和降低网络负载,但在这里,我泛指用于展示层与服务层之间的数据传输对象。



VO :

value object值对象

ViewObject表现层对象主要对应界面显示的数据对象。对于有有有另一一二个WEB页面,原应 SWT、SWING的有有有另一一二个界面,用有有有另一一二个VO对象对应整个界面的值。



POJO :

plain ordinary java object 简单java对象

自己感觉POJO是最常见最多变的对象,是有有有另一一二个上边对象,也是亲戚亲戚大伙儿最常打交道的对象。

有有有另一一二个POJO持久化过后很多很多很多很多PO

POJO、PO、DTO、VO有的是正确处理流程中的名字,有的是PO对应有有有另一一二个POJO,DTO对应有有有另一一二个POJO,VO对应有有有另一一二个POJO  

在过后 情況下PO、DTO、VO是指同有有有另一一二个POJO

  对于DTO来说,有的是过后 需用进行说明,很多很多很多很多DTO应该是有有有另一一二个“扁平的二维对象”,举个例子来说明:原应 User会关联若干个过后 实体(类事于Address、Account、Region等),这样 getUser()返回的UserInfo,与非 就需用把其关联的对象的DTO都一块儿返回呢?原应 很多很多很多很多语句,必然原应 数据传输量的大增,对于分布式应用来说,原应 涉及数据在网络上的传输、序列化和反序列化,這個 设计更不可接受。原应 getUser除了要返回User的基本信息外,还需用返回有有有另一一二个AccountId、AccountName、RegionId、RegionName,这样 ,请把那先 属性定义到UserInfo中,把有有有另一一二个“立体”的对象树“压扁”成有有有另一一二个“扁平的二维对象”。笔者目前参与的项目是有有有另一一二个分布式系统,该系统不管三七二十一,把有有有另一一二个对象的所有关联对象都转换为相同底部形态的DTO对象树并返回,原应 性能非常的慢。

  下面以有有有另一一二个时序图建立简单模型来描述上述对象在三层架构应用中的位置:

  VO(View Object):视图对象,用于展示层,它的作用是把某个指定页面(或组件)的所有数据封装起来。

  DO与PO的应用

  从上一节的例子中,细心的读者原应 会发现难题:既然getUser妙招返回的UserInfo不应该暗含password,这样 就不应该处在password這個 属性定义,但原应 一块儿有有有有另一一二个createUser的妙招,传入的UserInfo需用暗含用户的password,为什办?在设计层面,展示层向服务层传递的DTO与服务层返回给展示层的DTO在概念上是不同的,但在实现层面,亲戚亲戚大伙儿通常很少会很多很多很多很多做(定义有有有另一一二个UserInfo,甚至更多),原应 很多很多很多很多做并不见得很明智,亲戚亲戚大伙儿完全都能不能 设计有有有另一一二个完全兼容的DTO,在服务层接收数据的过后,不该由展示层设置的属性(如订单的总价应该由其单价、数量、折扣等决定),无论展示层与非 设置,服务层都一概忽略,而在服务层返回数据时,不该返回的数据(如用户密码),就不设置对应的属性。

  理论归理论,这到底还是分析设计层面的思维,与非 在实现层面需用很多很多很多很多做呢?一刀切的做法往往会得不偿失,下面我马上会分析应用中怎样才能做出正确的确定。

  到目前为止,相信亲戚亲戚大伙儿都原应 比较清晰的了解VO、DTO、DO、PO的概念、区别和实际应用了。通过上边的完全分析,亲戚亲戚大伙儿还都能不能 总结出有有有另一一二个原则:分析设计层面和实现层面完有的是有有有另一一二个独立的层面,即使实现层面通过有一种 技术手段都能不能 把有有有另一一二个完全独立的概念合二为一,在分析设计层面,亲戚亲戚大伙儿仍然(相当于在头脑中)需用把概念上独立的东西清晰的区分开来,這個 原则对于做好分析设计非常重要(工具越先进,往往会我都能不能 们越麻木)。第一篇系列博文抛砖引玉,大唱领域驱动设计的优势,但虽然领域驱动设计在现实环境中还是有种种的限制,需用确定性的使用,正如我在《田七的智慧教育》博文中提到,亲戚亲戚大伙儿只有永远的理想化的去确定所谓“最好的设计”,在必要的情況下,亲戚亲戚大伙儿还是要敢于放弃,原应 最相当于的设计才是最好的设计。很多很多很多很多,系列中的第二篇博文应该是讨论领取驱动设计的限制和怎样才能确定性的使用,但请原谅我的疏忽,下一篇系列博文会把這個 主题补上,敬请关注。

DAO:

data access object数据访问对象

這個 亲戚亲戚大伙儿最熟悉,和上边哪几个O区别最大,基本这样 互相转化的原应 性和必要.

主要用来封装对数据库的访问。通过它都能不能 把POJO持久化为PO,用PO组装出来VO、DTO

总结下我认为有有有另一一二个对象究竟是那先 O要看具体环境,在不同的层、不同的应用场合,对象的身份很多很多很多很多一样,过后对象身份的转化也是很自然的。就像你对男人来说就 是老公,对父母来说很多很多很多很多子女。设计那先 概念的初衷有的是为了唬人很多很多很多很多为了更好的理解和正确处理各种逻辑,我都能不能 们能更好的去用面向对象的妙招正确处理难题.

  上边很多很多很多很多用了有有有另一一二个简单的例子来说明VO与DTO在概念上的区别,本节原应 告诉你怎样才能在应用中做出正确的确定。

  PO(Persistent Object):持久化对象,它跟持久层(通常是关系型数据库)的数据底部形态形成一一对应的映射关系,原应 持久层是关系型数据库,这样 ,数据表中的每个字段(或若干个)就对应PO的有有有另一一二个(或若干个)属性。

http://kb.cnblogs.com/page/522348/

  原应 不同的项目和开发人员有不同的命名习惯,这里我首先对上述的概念进行有有有另一一二个简单描述,名字很多很多很多很多个标识,亲戚亲戚大伙儿重点关注其概念:

  DO与PO的区别

  VO与DTO的区别

  用有有有另一一二个例子来说明原应 会比较容易理解:类事于服务层有有有有另一一二个getUser的妙招返回有有有另一一二个系统用户,其中暗含有有另一一二个属性是gender(性别),对于服务层来说,它只从语义上定义:1-男性,2-男人,0-未指定,而对于展示层来说,它原应 需用用“帅哥”代表男性,用“美女”代表男人,用“秘密”代表未指定。说到这里,原应 你过后反驳,在服务层直接就返回“帅哥美女”不就行啥过后?对于大每项应用来说,这有的是难题,但设想一下,原应 需求允许客户都能不能 定制风格,而不同风格对于“性别”的表现妙招不一样,又原应 這個 服务一块儿供多个客户端使用(不同门户),而不同的客户端对于表现层的要求有所不同,这样 ,难题就来了。再者,回到设计层面上分析,从职责单一原则来看,服务层只负责业务,与具体的表现形式无关,过后,它返回的DTO,不应该有另一一二个劲出先与表现形式的耦合。

欢迎指正。

  DTO与DO的区别

  DTO与DO的应用

  上一篇文章作为有有有另一一二个引子,说明了领域驱动设计的优势,从本篇文章结束了了英语 ,笔者原应 结合自己的实际经验,谈及领域驱动设计的应用。本篇文章主要讨论一下亲戚亲戚大伙儿有另一一二个劲会用到的过后 对象:VO、DTO、DO和PO。



BO:

business object业务对象

主要作用是把业务逻辑封装为有有有另一一二个对象。這個 对象都能不能 包括有有有另一一二个或多个其它的对象。



画了个图,感觉这样 完全表达出自己的意思。。。。。谁帮忙完善下,最好能体现各个O在MVC中的位置

  原应 ORM框架的功能非常强大而大行其道,过后JavaEE也推出了JPA规范,现在的业务应用开发,基本上不需用区分DO与PO,PO完全都能不能 通过JPA,Hibernate Annotations/hbm隐藏在DO之中。虽然这样 ,但过后 难题亲戚亲戚大伙儿还需用注意:

  DO(Domain Object):领域对象,很多很多很多很多从现实世界中抽象出来的有形或无形的业务实体。



DTO :

Data Transfer Object数据传输对象

主要用于远程调用等需用几滴 传输对象的地方。

比如亲戚亲戚大伙儿一张表有100个字段,这样 对应的PO有的是100个属性。

过后亲戚亲戚大伙儿界面上过后显示10个字段,

客户端用WEB service来获取数据,这样 必要把整个PO对象传递到客户端,

这时亲戚亲戚大伙儿就都能不能 用只有这10个属性的DTO来传递结果到客户端,很多很多很多很多很多很多很多很多会暴露服务端表底部形态.到达客户端过后,原应 用這個 对象来对应界面显示,那先 时它的身份就转为VO

  以下场景需用优先考虑VO、DTO并存:

  亲戚亲戚大伙儿原应 会有个难题(在笔者参与的项目中,很多很多很多很多守护程序运行运行员有的是相同的疑惑):既然DTO是展示层与服务层之间传递数据的对象,为那先 还需用有有有另一一二个VO呢?对!对于绝大每项的应用场景来说,DTO和VO的属性值基本是一致的,过后亲戚亲戚大伙儿通常有的是POJO,过后没必要多此一举。但并不忘记这是实现层面的思维,对于设计层面来说,概念上还是应该处在VO和DTO,原应 两者有着本质的区别,DTO代表服务层需用接收的数据和返回的数据,而VO代表展示层需用显示的数据。

  对于DO来说,还有过后 需用说明:为那先 没了服务层中直接返回DO呢?很多很多很多很多都能不能 省去DTO的编码和转换工作,原应 如下:

  模型: