Question

DTO和实体之间有什么区别？详细信息，这些是我的问题：

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课程中放置什么内容？

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

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

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

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

Answer 1

DTO与...之间的差异实体：

实体是映射到表的类。 Dto主要是映射到“视图”层的类。需要存储的是实体和需要在网页上“显示”的是DTO。

示例：如果我想按如下方式存储员工模型：以员工为例，我需要存储男性/女性/其他性别。但是在JSP上我需要将所有三个值显示为'options'，以便用户可以选择一个。

@Entity
public class Employee{
//annotate with @Id and others

private Long id;
private String name;
private Gender gender; //this is enum viz Male,female
}
//Now extend Dto with employee

public EmployeeDto extends Employee{
Gender[] genders=Gender.values(); //put all gender types in array.
}

渲染jsp时我们可以给出

<select name="gender"> //pointed towards entity gender field.
  <option value="Male">Male</option>
  <option value="Female">Female</option>
  <option value="Other">Other</option>
</select>

然后在春天或其他一些框架中选择哪一个将在实体中选择性别。这是可能的，因为Dto在其中具有所有三个性别值。同样，根据情况，事情随之而来。 由于我们大多需要jsp上的大多数实体字段，我们按实体扩展dto。

Answer 2

简短答案：

实体可能是业务域的一部分。因此，它们可以实现行为并将其应用于域中的不同用例。
DTO仅用于将数据从一个进程或上下文传输到另一进程或上下文。因此，它们没有行为-除了非常基本且通常是标准化的存储和检索功能之外。

长答案：

“数据传输对象”（DTO）的定义很明确，在各种情况下，“实体”一词的解释都不同。

我认为，与“实体”一词最相关的解释是以下三种：

在企业级Java和jpa中：
“表示在数据库中维护的持久性数据的对象。”
在“领域驱动的设计”（由Eric Evans撰写）中：
“主要由其身份而不是其属性定义的对象。”
在“干净的体系结构”中（由Robert C. Martin撰写）：
“封装企业范围内关键业务规则的对象。”

Jee和Jpa社区主要将实体视为映射到的对象数据库表。这种观点与DTO的定义非常接近 -这就是其中很多困惑的根源。

在领域驱动设计的背景下，以及Robert Martins的观点，但是，实体是业务领域的一部分，因此可以并且应该实施行为。

Answer 3

这些是 the Microsoft 2014 MVC documentation 中给出的您希望从实体创建 DTO 的原因：

删除循环引用。
隐藏客户不应查看的特定属性。
省略一些属性以减少负载大小。
展平包含嵌套对象的对象图，使它们对客户更方便。
避免“过度发布”漏洞。（有关过度发布的讨论，请参阅模型验证。）
将服务层与数据库层分离。

但重要的是要了解这些都不是需要遵循的硬性规则。这完全取决于哪些数据最适合发送给您的客户以及哪种格式对您的客户最有用。

客户需要对数据做什么？

它会被编辑还是只是查看？
客户是否关心 int 列表的顺序？
是否需要插入或删除 int？
列表需要重新排列吗？

客户是否需要了解 1-1 或 1-many 关系或存在继承的事实？发送这些信息可能只是给客户端增加了不必要的复杂性。

在决定向客户端发送什么数据以及如何发送之前，需要回答这些和其他问题。

JAVA：实体与DTO之间的差异

3 个答案: