spring - 我应该使用 DTO 还是不使用？

Question

我正在使用 Spring 构建一个 Web 应用程序，现在我拥有一个实体、一个存储库、一个 RestController，并且可以在浏览器中访问端点。
我现在正在尝试将 JSON 数据返回到浏览器，并且我在各种指南中看到了有关 DTO 的所有这些内容。
我真的需要 DTO 吗？我不能将序列化逻辑放在实体本身上吗？

Answer 1

我认为，这是一个有点值得商榷的问题，简短的答案是:

It depends.

稍微长一点的答案
有很多人，在很多情况下，他们更喜欢一种方法(使用 DTO)而不是另一种(使用裸实体)，反之亦然；然而，没有更好的单一事实来源。
这在很大程度上取决于需求、您决定坚持的架构方法、(甚至)个人偏好和其他(与项目相关的)特定细节。
有些人甚至声称 DTO 是一种反模式；有些人喜欢使用它们；有些人认为，数据细化/调整应该发生在消费者/客户端(出于各种原因，其中一个可能是 API 更改无政策)。
话虽如此，是的，您可以简单地返回 @Entity直接来自您的 Controller 的实例(或实体列表)，这种方法没有问题。我什至会说，这不一定违反 SOLID 或 Clean Code 原则。同样，这取决于您使用响应的目的，您需要什么样的数据表示，对象的容量和目的应该是什么有问题等等。
在以下场景中，DTO 通常是一种很好的做法:

当你想从不同的资源聚合你的对象的数据时，即你想在持久层和业务(或 Web)层之间放置一些对象转换逻辑:
想象一下，您从数据库中获取 List<Employee> ;但是，从另一个 3rd 方网络服务，您还会收到每个 Employee 对象的一些补充员工数据，您必须将这些数据聚合到 Employee 对象中(聚合，或进行一些计算等。点是您想要的合并来自不同资源的数据)。当您可能想要使用 DTO 模式时，这是一个很好的例子。可重用，符合单一职责原则，与其他层隔离良好；

当您不一定要合并从不同来源接收的数据，但您想修改将要返回的实体时:
想象一下你有一个非常大的实体(有很多字段)，客户端调用相应的端点(前端应用程序、移动端或任何客户端)，不需要接收这个巨大的实体(或实体列表) )。如果您不顾客户端的要求，仍然发送原始/未更改的实体，则最终会低效地消耗网络带宽/负载(绰绰有余)，性能会变弱，并且通常只会浪费计算资源没有充分的理由。在这种情况下，您可能希望将原始实体转换为客户端需要的 DTO 对象(仅具有必填字段)。在这里，您甚至可能想要为一个实体、不同的消费者/客户端实现不同的 DTO 类。

但是，如果您确定您的表/关系表示(@Entity 类的实例)正是客户所需要的，我认为没有必要引入 DTO。

进一步支持这个想法，@Entity 可以在没有 DTO 的情况下返回到表示层

Java Persistence with Hibernate, Second Edition ，在 §3.3.2 中，甚至明确地激励它:

You can reuse persistent classes outside the context of persistence, in unit tests or in the presentation layer, for example. You can create instances in any runtime environment with the regular Java new operator, preserving testability and reusability;

休眠实体 do not need to be显式可序列化；

您可能还想看看 this question .