在任何情况下使用 DTO 都是一种好的做法吗？

Question

想象我有一个这样的实体：

@Entity
@Getter
@Setter
@ToString
@Table(name = "employeeSalary")
public class EmployeeSalary{

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private long id;

@Column(name = "fullName", nullable = false, length = 60)
private String fullName;

@Column(name = "salary", nullable = false)
private double salary;

@Column(name = "month", nullable = false)
@Enumerated(EnumType.STRING)
private Month month;

@Column(name = "year", nullable = false)
private Year year;

}

现在想象我像这样创建了 DTO：

@Data
@NoArgsConstructor
@AllArgsConstructor
public class EmployeeSalaryDTO {
private String fullName;
private double salary;
private Month month;
private Year year;
}

问题如下：在这种情况下创建 DTO 真的是一个好的实践吗？正如我们所看到的，DTO 和实体是相同的（唯一的区别是 DTO 没有 id，但让我们想象一下在这个 DTO 中也添加 id）创建这个 DTO 是否有意义。因为据我所知，在服务层中操作实体不是一个好主意，操作 DTO 然后将此 DTO 转换为实体是一个更好的选择，但正如我们所见，DTO 和实体完全相同，所以这样做有什么意义吗？当这两个类具有 100% 相似度时创建 DTO？或者无论如何创建它们是一个好的做法吗？ （因为在服务层操作实体不是一个好主意，更好的是操作dto然后转换为实体）

Answer 1

因此引入另一层作为 DTO 是一个很好的做法。因为在实体上操纵数据和操作似乎不是一个好的做法。一个好主意是在 DTO 中操作数据，然后使用模型映射器将它们转换为实体。所以总而言之，即使我们在实体和 DTO 中有完全相同的字段，使用 DTO 也是一个很好的实践。

Answer 2

我的工作方式是我为同一个域项目设置了 3 个类。假设我们有您的 EmployeeSalary 课程。然后我有 EmployeeSalaryDTO.java、EmployeeSalary.java 和 EmployeeSalaryEntity.java。

我将 EmployeeSalaryDTO 用于其自己的定义和目的，即“数据传输对象”。例如，将我想要的数据发送给客户或其他服务。

然后我将 EmployeeSalary 用于域目的。在这里，我可以在此类中创建方法来帮助我使用它。例如，“calculateSalary()”方法将在我的服务类中使用。

最后我们有 EmployeeSalaryEntity，它仅用于在数据库中存储和检索数据。从某种意义上说，它与 DTO 非常相似。唯一的区别是 DTO 是公共接口，而这更多的是私有的。例如，在您的示例中，您可以在实体类中有一个名为“createdBy”的字段，用于存储创建该对象的用户。但您不想在公共界面中显示此属性，因此您不想在 DTO 类中拥有此属性。最多你可以将它放在你的域类（EmployeeSalary.class）中以对其进行一些操作。

希望有帮助。