实体和DTO之间的区别

Question

DTO 和实体有什么区别？详细来说，这些是我的问题：

1. DTO 应该有哪些字段？例如我的实体类是：

    @Entity
   public class MyFirstEntity implements Serializable {

       @Id @GeneratedValue
       private Long id;

       private String stringData;

       @OneToOne
       private MySecondEntity mySecondEntity;

       @OneToMany
       private List<MySecondEntity> mySecondEntitesList;

   }

   @Entity
   public class MySecondEntity implements Serializable {

       @Id @GeneratedValue
       private Long id;

       private Integer integerData;

       @ManyToOne
       private MyFirstEntity myFirstEntity;

   }

有一个单向连接（一对一）和一个双向连接（多对一），一个简单的字符串和整数数据，当然还有 id。在 MyFirstDTO 和 MySecondDTO 类中放什么？

1. 如果实体之间存在继承关系，那么我应该如何在 DTO 中表示它？例如：

    @Entity
   public class MyFirstEntity extends MySecondEntity {
       ....
   }

   @Entity
   public class MyFirstDTO extends MySecondDTO {
       ....
   }

1. 我应该如何使用它们？例如，我发现：我正在从事一个网络项目。该网页的用户想要注册。他/她填写表格，并将其发送到服务器。在服务器端，我首先创建一个 DTO，因为它的字段有验证。我从 DTO 创建一个实体并将其保存到数据库中。当有实体请求时，我将请求的实体转换为 DTO，并在客户端将其提供给用户。这是一个很好的想象力吗？

原文由 Display Name 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

简短回答：

• 实体 可能是 业务领域的一部分。因此，它们可以实现行为并应用于域内的不同用例。

• DTO 仅用于将数据从一个进程或上下文传输到另一个进程或上下文。因此，它们没有行为——除了非常基本且通常标准化的存储和检索功能。

长答案：

虽然术语“数据传输对象”(DTO) 的定义非常明确，但术语“实体”在不同的上下文中有不同的解释。

在我看来，对“实体”一词最相关的解释是以下三种：

1. 在实体关系和 ORM 框架的上下文中——特别是 Enterprise Java 和 Jpa：

   “表示在数据库中维护的持久数据的对象。”

2. 在“领域驱动设计”的背景下（Eric Evans）：

   “主要由其身份而非属性定义的对象。”

3. 在“清洁架构”（Robert C. Martin）的背景下：

   “一个封装企业范围关键业务规则的对象。”

Jee 和 Jpa 社区主要将实体视为映射到数据库表的对象。这种观点非常接近 DTO 的定义——这可能是很多混淆的根源。

然而，在领域驱动设计的上下文中，以及 Robert Martins 的观点中，实体是业务领域的一部分，因此可以而且应该实现行为。

原文由 Andreas Vogl 发布，翻译遵循 CC BY-SA 4.0 许可协议