在MVC中，数据传输对象通常用于将域模型映射到最终由视图显示的更简单的对象。

从维基百科:

数据传输对象(DTO)，以前称为值对象或VO 一种用于在软件应用程序之间传输数据的设计模式 子系统。dto通常与数据访问一起使用 对象从数据库检索数据。

DTO的定义可以在Martin Fowler的网站上找到。dto用于将参数传递给方法并作为返回类型。很多人在UI中使用它们，但其他人从它们扩展域对象。

DTO是一个愚蠢的对象——它只保存属性，有getter和setter，但没有任何其他重要的逻辑(除了一个compare()或equals()实现)。

通常MVC中的模型类(假设这里是。net MVC)是dto，或者dto的集合/聚合

数据传输对象是用于封装数据并将数据从应用程序的一个子系统发送到另一个子系统的对象。

dto最常被n层应用程序中的服务层用于在自身和UI层之间传输数据。这样做的主要好处是减少了分布式应用程序中需要通过网络发送的数据量。它们还可以在MVC模式中创建很棒的模型。

dto的另一个用途是封装方法调用的参数。如果一个方法需要超过4个或5个参数，这可能很有用。

在使用DTO模式时，还可以使用DTO汇编程序。汇编程序用于从域对象创建dto，反之亦然。

从域对象转换到DTO并再转换回来可能是一个代价高昂的过程。如果您不是在创建分布式应用程序，那么您可能不会从这个模式中看到任何好处，Martin Fowler在这里解释道。

一般来说，值对象应该是不可变的。类似于Java中的Integer或String对象。我们可以使用它们在软件层之间传输数据。如果软件层或服务运行在不同的远程节点上，比如在微服务环境中或在遗留的Java企业应用程序中。我们必须几乎完全复制两个类。这就是我们遇到dto的地方。

|-----------|                                                   |--------------|
| SERVICE 1 |--> Credentials DTO >--------> Credentials DTO >-- | AUTH SERVICE |
|-----------|                                                   |--------------|

在传统的Java企业系统中，dto可以包含各种EJB内容。

我不知道这是否是一个最佳实践，但我个人在我的Spring MVC/Boot项目中使用值对象是这样的:

        |------------|         |------------------|                             |------------|
-> Form |            | -> Form |                  | -> Entity                   |            |
        | Controller |         | Service / Facade |                             | Repository |
<- View |            | <- View |                  | <- Entity / Projection View |            |
        |------------|         |------------------|                             |------------|

控制器层不知道实体是什么。它与表单和视图值对象通信。表单对象有JSR 303验证注释(例如@NotNull)，视图值对象有Jackson注释用于自定义序列化。(例如@JsonIgnore)

服务层通过使用实体对象与存储库层通信。实体对象上有JPA/Hibernate/Spring Data注释。每一层只与较低的层通信。由于循环依赖关系，层间通信被禁止。

User Service ----> XX CANNOT CALL XX ----> Order Service

一些ORM框架具有通过使用额外的接口或类进行投影的能力。因此存储库可以直接返回View对象。在那里你不需要额外的转换。

例如，这是我们的User实体:

@Entity
public final class User {
    private String id;
    private String firstname;
    private String lastname;
    private String phone;
    private String fax;
    private String address;
    // Accessors ...
}

但是你应该返回一个分页的用户列表，只包括id，名，姓。然后，您可以为ORM投影创建一个视图值对象。

public final class UserListItemView {
    private String id;
    private String firstname;
    private String lastname;
    // Accessors ...
}

您可以轻松地从存储库层获得分页结果。多亏了spring，您还可以只使用接口进行投影。

List<UserListItemView> find(Pageable pageable);

不用担心BeanUtils的其他转换操作。复制方法工作得很好。

To me the best answer to the question what is a DTO is that DTO's are simple objects that should not contain any business logic or methods implementation that would require testing. Normally your model (using the MVC pattern) are intelligent models, and they can contain a lot of/some methods that do some different operations for that model specifically (not business logic, this should be at the controllers). However, when you transfer data (eg. calling a REST (GET/POST/whatever) endpoint from somewhere, or consuming a webservice using SOA, etc...) you do not want to transmit the big sized object with code that is not necessary for the endpoint, will consume data, and slow down the transfer.

数据传输对象(DTO)描述了“承载数据的对象” (维基百科)或“用于封装数据的对象”， 并将它从应用程序的一个子系统发送到另一个子系统”(堆栈溢出 答案)。

DefN

DTO是硬编码的数据模型。它只解决了由硬编码的生产过程处理的数据记录建模问题，其中所有字段在编译时都是已知的，因此可以通过强类型属性访问。

相反，动态模型或“属性包”解决了在运行时创建生产流程时对数据记录建模的问题。

瓦尔

DTO可以用字段或属性建模，但有人发明了一种非常有用的数据容器，称为Cvar。它是一个值的引用。当使用引用属性对DTO建模时，可以将模块配置为共享堆内存，从而在堆内存上协同工作。这完全消除了代码中的参数传递和O2O通信。换句话说，具有引用属性的dto允许代码实现零耦合。

    class Cvar { ... }

    class Cvar<T> : Cvar
    {
        public T Value { get; set; }
    }

    class MyDTO
    {
        public Cvar<int> X { get; set; }
        public Cvar<int> Y { get; set; }
        public Cvar<string> mutableString { get; set; } // >;)
    }

来源:http://www.powersemantics.com/

动态dto是动态软件的必要组件。要实例化动态流程，编译器的一个步骤是将脚本中的每台机器绑定到脚本定义的引用属性。动态DTO是通过将cvar添加到集合来构建的。

    // a dynamic DTO
    class CvarRegistry : Dictionary<string, Cvar> { }

论点

注意:由于Wix将使用dto组织参数标记为“反模式”，因此我将给出权威的意见。

    return View(model);  // MVC disagrees

我的协作架构取代了设计模式。参考我的网络文章。

Parameters provide immediate control of a stack frame machine. If you use continuous control and therefore do not need immediate control, your modules do not need parameters. My architecture has none. In-process configuration of machines (methods) adds complexity but also value (performance) when the parameters are value types. However, reference type parameters make the consumer cause cache misses to get the values off the heap anyway -- therefore, just configure the consumer with reference properties. Fact from mechanical engineering: reliance on parameters is a kind of preoptimization, because processing (making components) itself is waste. Refer to my W article for more information. http://www.powersemantics.com/w.html.

如果Fowler和他的公司了解其他架构，他们可能会意识到dto在分布式架构之外的好处。程序员只知道分布式系统。集成协作系统(又名生产又名制造)是我自己的架构，因为我是第一个用这种方式写代码的人。

Some consider the DTO an anemic domain model, meaning it lacks functionality, but this assumes an object must own the data it interacts with. This conceptual model then forces you to deliver the data between objects, which is the model for distributed processing. However on a manufacturing line, each step can access the end product and change it without owning or controlling it. That's the difference between distributed and integrated processing. Manufacturing separates the product from operations and logistics.

There's nothing inherently wrong with modeling processing as a bunch of useless office workers who e-mail work to one another without keeping an e-mail trail, except for all the extra work and headache it creates in handling logistics and return problems. A properly modeled distributed process attaches a document (active routing) to the product describing what operations it came from and will go to. The active routing is a copy of the process source routing, which is written before the process begins. In the event of a defect or other emergency change, the active routing is modified to include the operation steps it will be sent to. This then accounts for all the labor which went into production.

数据传输对象背后的原理是创建新的数据对象，其中只包括特定数据事务所需的必要属性。

福利包括:

使数据传输更加安全 如果删除所有不必要的数据，则减少传输大小。

阅读更多信息:https://www.codenerd.co.za/what-is-data-transfer-objects

我会把DTO解释给我的孩子

我的儿子，数据传输对象(又名DTO) **用于封装我们从一个端点发送到另一个端点的数据。 使用DTO为系统中的端点定义输入和输出接口 在这种情况下，可以将系统看作端点的集合。端点可以是任何相互通信的东西(移动应用程序，web应用程序，后端API)。

所有功劳都归里克-安德森所有

生产应用程序通常限制使用模型子集输入和返回的数据。这背后有很多原因，安全是一个主要原因。模型的子集通常被称为数据传输对象(DTO)、输入模型或视图模型。

DTO可用于:

防止over-posting。 隐藏客户端不应该查看的属性。 为了减少有效负载大小，省略一些属性。 扁平化包含嵌套对象的对象图。 扁平化的对象图对客户来说更方便。

DTO方法的实际实现，由rick - anderson在微软Web api最佳教程和实践中使用c#和asp.net Core 5:

一些程序员使用DTO来区分将通过API传递的最终对象数据。它基本上是端点的有效载荷对象。比如，你可以将你传递给服务器的联系人表单值对象命名为contactFormDto或contactFromPayload，然后你或任何其他程序员都知道你在那个对象中拥有的是数据的最终形状，它将通过网络传播。