了解dto概念,什么是DTO

了解dto概念

  此博文收集整理了一些主流的文章对于DTO模式的解读,他们大体相似而又各有所不同。对于设计模式的解读也是一个仁者见仁智者见智的事情,不过设计模式往往都是前辈们在遇到一类特定的问题下而总结的经验和智慧。看不同大牛对同一概念的解读,对比思考,本身就是对于我们思维的一次洗礼。(所有文章均贴有出处,在此感谢大牛们的辛勤劳作。)

什么是DTO?

百度百科如何解读的?

DTO是Data Transfer Object 的简写,既数据传输对象。

是一种设计模式之间传输数据的软件应用系统。数据传输目标往往是数据访问对象从数据库中检索的数据。数据传输对象与数据交互对象或数据访问对象之间是一个不具备有任何行为除了存储和检索的数据。(访问和存取器)

维基百科是如何解读的?

A data transfer object(DTO) is an  object that carries data between two process.

The difference between data transfer and business objects or data access objects is that a DTO does not have any behavior except for storage and retrieval of its own data(mutators and accesssors).DTOs are simple objects that should not contain any business logic that would require testing.

和百度百科不同的是,DTO和MO(Model Object)与BO(Business Object)的不同之处在于DTO没有任何业务行为(贫血模式)只作为数据的存储。

原链接:https://en.wikipedia.org/wiki/Data_transfer_object

References 下有许多有料的参考文章。

有经典的文章是如何解读的?

博客园dax.net的观点:

表现层于应用层之间是通过DTO来进行交互的,数据传输对象是没有行为的POCO对象,他的目的是为了对领域对象进行数据封装,实现层与层之间的数据传递。为何不直接将领域对象进行数据传递?因为领域对象更注重领域,DTO更注重数据。由于“富领域模型”的特点,这样会直接将领域对象的行为暴露给表现层。

DTO本身不是业务对象,他是根据UI需求进行设计的。简单来说Model面向业务,我们是通过业务来定义Model的。而DTO是面向UI,通过UI的需求来定义的,通过DTO我们实现了表现层与Model层之间的解耦,表现层不引用Model。如果开发过程中我们的模型变了,而界面没变,我们只需改Model而不需要去改动表现层。

原文链接:http://www.cnblogs.com/daxnet/archive/2010/07/07/1772584.html

博客园loveis715的观点:

DTO用于在服务器与客户端之间或服务器与服务器之间进行数据传递,文章从问题出发,然后深入浅出的讨论了DTO以及相关的概念,值得一读。

原文链接:http://www.cnblogs.com/loveis715/p/4379656.html

DTO – 服务实现中的核心数据

微软MSDN的观点:

Create a data transfer object(DTO) that holds all data that is required for the remote call.Modify the remote signature to accept the DTO as the single parameter and to return a single DTO to the client.After the calling application receives the DTO and and stores it as a local object , the application can make a series of individual procedure calls to the DTO without incurring the overhead of remote calls.

大致的观点是DTO可以有效的减少请求数量,文章中包含示例,讨论了问题的由来(为什么需要DTO),以及DTO使用过程中的一些注意事项。不过在文章的开头说到这个设计模式已经过时了,从此来看技术的更新迭代真的是很快,只是不知道DTO为什么过时了?以及哪些新的技术替代了DTO?

原文链接:

https://msdn.microsoft.com/en-us/library/ms978717.aspx

Pattern of Enterprise  Application Architecture 作者观点:

An object carries data between two processes in order to reduce the number of method calls.

When you are working with a remote interface,such as Remote Facade,each call to it is expensive.As a result you should reduce the number of calls, and that means that you need to transfer more data with each call.One way to do this is to use  lots of parameters.

However, this is often awkward  to program - indeed,it‘s often impossible with languages such as Java that return only a single value.

The solution is to create a Data Transfer Object that can hold all the data for the call.It needs to be serializable to go across the connection.Usually an assembler is used on the server side to transfer data between the DTO and any domain objects.

Although the main reason for using a Data Transfer Object is to batch up what would be mutiple remote calls into single call,it‘s worth mentioning that another advantage is to encapsulate the serialization mechanism for transferring data over write.By encapsulating the serialization like this ,the DTOs keep this logic out of the rest of the code and also provide a clear point to change  serialization should you wish.

原文链接:

https://martinfowler.com/eaaCatalog/dataTransferObject.html

观点和loveis715有一致的地方,简而言之DTO的存在就是为了帮助我们减少客户端请求而降低服务器压力,提升效率。作者还有一个观点大概是指在使用DTO后我们可以灵活定义数据模型,同时将数据模型和逻辑剥离开了。

时间: 2024-10-18 09:40:15

了解dto概念,什么是DTO的相关文章

DTO概念

在开发过程中用到了DTO,简单了解了一下. DTO:数据传输对象,用来连接表现层和应用层之间的数据交互.数据传输对象是没有行为的POJO对象,它的目的只是为了对领域对象进行数据封装,实现层与层之间的数据传递.我们不直接将领域对象用于数据传递,因为领域对象更注重领域,DTO更注重数据.而且,由于“富领域模型”的特点,直接使用领域模型会将领域对象的行为暴露给表现层.DTO本身不是业务对象.数据传输对象是根据UI的需求而设计的,而不是根据领域对象设计的.简单来说Model面向业务,我们通过业务定义Mo

VO、DTO与领域模型的概念

业务对象模型(也叫领域模型 domain model)是描述业务用例实现的对象模型.它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象.业务对象模型从业务角色内部的观点定义了业务用例.该模型为产生预期效果确定了业务人员以及他们处理和使用的对象("业务类和对象")之间应该具有的静态和动态关系.它注重业务中承担的角色及其当前职责.这些模型类的对象组合在一起可以执行所有的业务用例. 参考博文: 领域模型的概念 VO.DTO与领域模型

pojo与DTO的区别

ational Mapping(对象关系映射)的缩写.通俗点讲,就是将对象与关系数据库绑定,用对象来表示关系数据.在O/R Mapping的世界里,有两个基本的也是重要的东东需要了解,即VO,PO. VO,值对象(Value Object),PO,持久对象(Persisent Object),它们是由一组属性和属性的get和set方法组成.从结构上看,它们并没有什么不同的地方.但从其意义和本质上来看是完全不同的. 1.VO是用new关键字创建,由GC回收的. PO则是向数据库中添加新数据时创建,

使用AutoMapper实现Dto和Model的自由转换(上)

在实际的软件开发项目中,我们的"业务逻辑"常常需要我们对同样的数据进行各种变换.例如,一个Web应用通过前端收集用户的输入成为Dto,然后将Dto转换成领域模型并持久化到数据库中.另一方面,当用户请求数据时,我们又需要做相反的工作:将从数据库中查询出来的领域模型以相反的方式转换成Dto再呈现给用户.有时候我们还会面临更多的数据使用需求,例如有多个数据使用的客户端,每个客户端都有自己对数据结构的不同需求,而这也需要我们进行更多的数据转换. 频繁的数据转换琐碎而又凌乱,很多时候我们不得不:

javabean、DTO、VO

一.javabean 一. javabean 是什么? Bean的中文含义是“豆子”,顾名思义,JavaBean是指一段特殊的Java类, 就是有默然构造方法,只有get,set的方法的java类的对象. 专业点解释是: JavaBean定义了一组规则JavaBean就是遵循此规则的平常的Java对象 满足这三个条件:     1.执行java.io.Serializable 接口  2.提供无参数的构造器   3.提供getter 和 setter方法访问它的属性. 简单地说,JavaBean

如何根据动态SQL代码自动生成DTO

当前的状况 一般做数据库相关开发, 除非学习, 否则很少有人愿意直接使用JDBC.本来Java代码就比较啰嗦了,而直接用JDBC写代码之啰嗦简直有些令人发狂!所以在实际开发过程中,我们通常都会使用一些框架/库来帮助我们操作数据库.而且开源市场上的选择也比较多,就我个人接触到的有:Hibernate,MyBatis,JdbcTemplate,DbUtils,ActiveRecord,JavaLite等等. 这些框架都能大幅的提高开发效率,对于一些基本CRUD操作来说,虽然各有差异,但总的来说基本是

应用程序框架实战三十四:数据传输对象(DTO)介绍及各类型实体比较(转)

本文将介绍DDD分层架构中广泛使用的数据传输对象Dto,并且与领域实体Entity,查询实体QueryObject,视图实体ViewModel等几种实体进行比较. 领域实体为何不能一统江湖? 当你阅读我或其它博主提供的示例代码时,会发现几种类型的实体,这几种实体初步看上去区别不大,只是名称不同,特别在这些示例非常简单的情况下更是如此.你可能会疑惑为何要搞得这么复杂,采用一种实体不是更好? 在最理想的情况下,我们只想采用领域实体Entity进行所有的操作. 领域实体是领域层的核心,是业务逻辑的主要

【AutoMapper官方文档】DTO与Domin Model相互转换(中)

写在前面 AutoMapper目录: [AutoMapper官方文档]DTO与Domin Model相互转换(上) [AutoMapper官方文档]DTO与Domin Model相互转换(中) 持续更新中... 本篇目录: Custom Type Converters-自定义类型转换器 Custom Value Resolvers-自定义值解析器 Null Substitution-空值替换 Containers-IoC容器 后记 随着AutoMapper的学习深入,发现AutoMapper在对

DTO学习系列之AutoMapper(三)

本篇目录: Custom Type Converters-自定义类型转换器 Custom Value Resolvers-自定义值解析器 Null Substitution-空值替换 Containers-IoC容器 后记 随着AutoMapper的学习深入,发现AutoMapper 在对象转换方面(Object-Object Mapping)还蛮强大的,当时使用AutoMapper的场景是DTO与Domin Model相互转换,所以文章的标题就是这个(标题有误),其实AutoMapper不止在