实体与DTO的区别

Question

@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;

}

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

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

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

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

Answer 1

简短的回答：

>

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

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

在“Clean Architecture”（Robert C.Martin著）的上下文中:
“封装企业范围内关键业务规则的对象。”

JEE和JPA社区主要将实体视为映射到数据库表的对象。这种观点非常接近DTO的定义--这可能是造成许多混乱的原因。

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