假设我有这样一个实体:
@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和Entity是相同的(唯一的区别是DTO没有id,但让我们想象一下在这个DTO中也添加id)创建这个DTO有意义吗?因为我知道在服务层操作实体不是一个好主意,所以更好的选择是操作DTO,然后将这个DTO转换为实体,但正如我们所看到的,DTO和实体是完全相同的,所以当我们在这两个类中有100%的相似性时,创建DTO有意义吗?或者不管怎样,创建它们是一种很好的做法吗?(因为在服务层操作实体不是一个好主意,所以更好的做法是操作dto,然后再转换为实体)
1条答案
按热度按时间6kkfgxo01#
因此,引入另一层作为DTO是一个很好的实践。因为在实体上操作数据和操作似乎不是一种好做法。一个好主意是在DTO中操作数据,然后使用模型Map器将它们转换为实体的数据。因此,一句话,即使我们在Entity和DTO中有完全相同的字段,使用DTO也是一个很好的实践。