[TIL] DTO

책에서는 서비스단에서 dto를 매개변수로 많이 쓰고 있는데,

규모가 커졌을때, 그리고 서로 엮었을 때를 생각하면,

dto를 매개변수를 받는게 치명적일 수 있다라는 것을 듣게 된 후,

Dto에 대해서 다시 한번 정리하게 되었다.

DTO(데이터 전송 객체)

DTO <-> Entity 어떻게 할까 ? 

@Getter
@NoArgsConstructor
@Entity
public class User {
@Id
@GeneratedValue(strategy= GenerationType.AUTO)
private long id;

    private String name;

    private String password;
    
    private String email;
    
    @Builder
    public User(String name, String password, String email) {
        this.name = name;
        this.password = password;
        this.email = email;
    }
}


Dto class에 toEntity 함수를 정의해서 entity로 바꿀수 있다.  

(DB에 등록할때 쓰임)

@Getter
@NoArgsConstructor
public class SaveRequestUserDto {

    private int id;
    private String name;
    private String password;
    private String email;

    @Builder
    public SaveRequestUserDto(int id, String name, String password, String email){
        this.id = id;
        this.name = name;
        this.password = password;
        this.email = email;
    }
    
    //dto -> entity
    public User toEntity(){
        return User.builder()
                .id(id)
                .name(name)
                .password(password)
                .email(email)
                .build();
    }
}


Dto class에 생성자를 만들때 파라미터를 entity로 넣으면서 매핑된 Dto를 만들 수 있다.

(DB를 조회할때 쓰임)

@Getter
@NoArgsConstructor
public class ResponseUserDto {

    private int id;
    private String name;
    private String password;
    private String email;

    //entity -> dto
    public ResponseUserDto(User entity){
        this.id = entity.id;
        this.name = entity.name;
        this.password = entity.password;
        this.email = entity.email;
    }
}

또한, Entity는 Setter X

Setter를 무분별하게 사용하다보면 여기저기서 entity값을 변경할수 있기 때문에 일관성을 보장X

Service는 다른 Service에서도 서로 호출 될수 있기 때문에, 도메인 객체들이 사용되어야 하고,

DTO는 데이터를 옮기기 위한 목적이므로 이것은 Controller 단에서 사용해야 함!