什么是数据传输对象 (DTO)？

Question

在MVC中模型类是DTO吗？ 如果不是，有什么区别，我们都需要吗？

Answer 1

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

N 层应用程序中的服务层最常使用 DTO 在其自身和 UI 层之间传输数据。 这里的主要好处是它减少了分布式应用程序中需要通过线路发送的数据量。 他们还在 MVC 模式中制作了很棒的模型。

DTO 的另一个用途是封装方法调用的参数。 如果方法采用四个或五个以上参数，这可能很有用。

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

从域对象到 DTO 的转换以及再次转换可能是一个成本高昂的过程。 如果您不创建分布式应用程序，您可能不会从该模式中看到任何巨大的好处，正如Martin福勒在此解释。

Answer 2

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

Answer 3

DTO 是一个哑对象 - 它只保存属性并具有 getter 和 setter，但没有其他任何重要的逻辑（除了 compare() 或 equals()执行）。

MVC 中的典型模型类（假设此处为 .net MVC）是 DTO，或 DTO 的集合/聚合

Answer 4

一般来说，值对象应该是不可变的。 就像 Java 中的 Integer 或 String 对象一样。 我们可以使用它们在软件层之间传输数据。 如果软件层或服务运行在不同的远程节点中，例如微服务环境或旧版 Java 企业应用程序中。 我们必须制作两个类的几乎完全相同的副本。 这就是我们遇到 DTO 的地方。

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

在遗留的 Java Enterprise Systems 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、firstname、lastname。 然后您可以创建一个用于 ORM 投影的视图值对象。

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

您可以轻松地从存储库层获取分页结果。 感谢 spring，您还可以仅使用接口进行投影。

List<UserListItemView> find(Pageable pageable);

不用担心其他转换操作 BeanUtils.copy 方法工作得很好。

Answer 5

1. 对我来说，什么是 DTO 问题的最佳答案是 DTO 是简单的对象，不应包含任何需要测试的业务逻辑或方法实现< /em>.
2. 通常，您的模型（使用 MVC 模式）是智能模型，它们可以包含许多/一些方法，专门为该模型执行一些不同的操作（不是业务逻辑，这应该在控制器上）。 但是，当您传输数据（例如，从某处调用 REST（GET/POST/其他）端点，或使用 SOA 消费 Web 服务等...）时，您不想使用端点不需要的代码传输大尺寸对象，这会消耗数据并减慢传输速度。

Answer 6

所有功劳均归于 Rick-Andreson

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

DTO 可用于 PHOFF：

• 防止过度发布。
• 隐藏客户端不应查看的属性。
• 省略一些属性以减少有效负载大小。
• 展平包含嵌套对象的对象图。
• 扁平化的对象图对客户来说更方便。

DTO 方法的实际实现，由 Rick-Andreson 在 Microsoft Web API使用 C# 和 ASP .Net Core 5 的最佳教程和实践：

Answer 7

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

来自维基百科：

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

Answer 8

数据传输对象背后的原则是创建仅包含特定数据事务所需的必要属性的新数据对象。

好处包括：

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

了解更多：https://www.codenerd.co.za/what-是数据传输对象

Answer 9

一些程序员使用 DTO 来区分将通过 API 传递的最终对象数据。 因此，它基本上是端点的有效负载对象。 例如，您可以将传递给服务器的联系表单值对象命名为 contactFormDto 或 contactFromPayload，然后您或任何其他程序员知道该对象中的内容是数据的最终形状，即打算通过网络去旅行。

Answer 10

我会向我的孩子解释 DTO

我的儿子，数据传输对象（又名 DTO）** 用于封装我们从一个端点发送到另一个端点的数据。
使用 DTO 定义系统中端点的输入和输出接口

<块引用>

在这种情况下，将系统视为端点的集合。 端点可以是相互通信的任何内容（移动应用程序、Web 应用程序、后端 API）。

Answer 11

数据传输对象（DTO）描述“携带数据的对象
进程之间”（维基百科）或“用于封装数据的对象，
并将其从应用程序的一个子系统发送到另一个子系统”（堆栈内存溢出）
回答）。

Answer 12

DefN

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

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

Cvar

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 是动态软件的必要组件。 要实例化动态进程，一个编译器步骤是将脚本中的每台机器绑定到脚本定义的引用属性。 通过将 Cvar 添加到集合来构建动态 DTO。

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

争论

注意：因为Wix将使用DTO来组织参数标记为“反模式”，所以我将给出一个权威的意见。

    return View(model);  // MVC disagrees

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

参数提供对堆叠框架机器的即时控制。 如果您使用连续控制，因此不需要立即控制，则您的模块不需要参数。 我的架构没有。 当参数是值类型时，机器（方法）的进程内配置增加了复杂性，但也增加了价值（性能）。 但是，引用类型参数会使使用者导致缓存未命中以从堆中获取值——因此，只需使用引用属性配置使用者即可。 来自机械工程的事实：对参数的依赖是一种预优化，因为加工（制造组件）本身就是浪费。 请参阅我的 W 文章了解更多信息。 http://www.powersemantics.com/w.html。

如果 Fowler 和他的公司了解任何其他架构，他们可能会意识到分布式架构之外的 DTO 的好处。 程序员只知道分布式系统。 集成协作系统（又名生产又名制造）是我必须声称是我自己的架构的东西，因为我是第一个以这种方式编写代码的人。

有些人认为 DTO 是一种贫乏的领域模型，这意味着它缺乏功能，但这假设对象必须拥有与其交互的数据。 然后，这个概念模型迫使您在对象之间传递数据，这就是分布式处理的模型。 然而，在生产线上，每个步骤都可以访问最终产品并对其进行更改，而无需拥有或控制它。 这就是分布式处理和集成处理之间的区别。 制造将产品与运营和物流分开。

将处理建模为一群无用的办公室工作人员，他们通过电子邮件相互发送工作而不保留电子邮件跟踪，这本身并没有什么问题，除了在处理物流和退货问题时产生的所有额外工作和头痛之外。 正确建模的分布式流程会将一个文档（主动路由）附加到产品中，描述它来自和将进行的操作。 活动路由是流程源路由的副本，在流程开始之前写入。 如果出现缺陷或其他紧急变化，活动路由将被修改以包括它将被发送到的操作步骤。 这就说明了投入生产的所有劳动力。