foreword
Refer to the article link
to summarize the concept and basic use of DTO
Introduction to DTOs
DTO itself is not a business object, it is designed according to UI requirements. Simply put, Model is business-oriented, and we define Model through business.
DTO is UI-oriented and defined by UI requirements. Through DTO, we realize the decoupling between the presentation layer and the Model layer, and the presentation layer does not refer to the Model. If our model changes during the development process, but the interface remains unchanged, we only need to change the Model without changing the presentation layer.
DTO code example
@Data
@EqualsAndHashCode(callSuper = false)
@Accessors(chain = true)
@TableName("tb_user")
public class User implements Serializable {
private static final long serialVersionUID = 1L;
@TableId(value = "id", type = IdType.AUTO)
private Long id;
private String phone;
private String password;
private String nickName;
private String icon = "";
private LocalDateTime createTime;
private LocalDateTime updateTime;
}
Our original user class
is model-oriented.
If the front end only needs to display the user name
, then we should not pass sensitive data such as passwords.
The UI-oriented DTO should be defined
and when our business changes the back-end model layer to add new attributes such as address, etc.,
there is no need to change the UI-oriented DTO to achieve a certain degree of decoupling
So we use DTO
advantage
1 to achieve a certain view layer and Model layer decoupling
2 can prevent sensitive information from leaking
3 if using session to access less data can save memory space
use DTO
@Data
public class UserDTO {
private Long id;
private String nickName;
private String icon;
}