Dto vs Entity

DTO란 Data Transfer Object의 약자로 각 계층간에 데이터 교환을 위한 객체이다.

view에서 controller로 controller에서 service로 모두 dto를 거쳐서 데이터의 교환이 이뤄진다.

Dto는 getter/setter 메소드만을 가지며 로직 또한 가지지 않는 순수한 데이터 객체로 

dto는 데이터 전송만을 위한 객체이다.

 

그러면 Entity란 DB의 테이블과 매칭이 될 클래스를 뜻한다. 즉 테이블과 직접적으로 링크가 될 클래스로 

@Column이나 @Id를 통해 직접적으로 db테이블과 매칭을 시켜주는 클래스이다.

선언은 @Entity로 한다.

 

DTO의 형태

 

@Getter
@AllArgsConstructor
@NoArgsConstructor
public class BoardRequestDto {		// 요청할때의 DTO
    private String title;
    private String name;
    private String contents;
    private String password;
}

@Getter
@NoArgsConstructor
public class BoardResponseDto {		// 응답할때의 DTO
    private Long id;
    private String title;
    private String name;
    private String contents;
    private LocalDateTime createdAt;
    private LocalDateTime modifiedAt;
}

DTO의 요청할때와 응답할때의 형태가 다른 이유는 데이터의 보안의 이유이다.

예를 들면 회원가입을 할때 아이디 비밀번호 회원이름 등 회원의 정보를 적은 데이터를 보낸다고 할때

요청과 응답하는 DTO가 같다면은 응답을 받을때 비밀번호가 그대로 노출되는 문제가 발생한다.

 

Entity의 형태

@Getter
@Entity
@NoArgsConstructor
public class Board extends Timestamped {
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;

    @Column(nullable = false)
    private String title;

    @Column(nullable = false)
    private String name;

    @Column(nullable = false)
    private String contents;

    @Column(nullable = false)
    private String password;
}

각각의 필드에 DB테이블과 매칭을 시켜주기위해 @Column으로 선언해 매칭시켜준다.

 

DTO와 Entity를 나눠놓은 이유

1. 보안의 이유

Entity에는 db테이블과 매칭되는 모든 필드가 모여 있기 때문에 이러한 entity의 형태를 그대로 반환한다면

그 과정에서 비밀번호가 그대로 client에게 흘러갈 수도 있는 보안의 이유가 있다.

반환을 할때 모든 필드가 필요가 없을수도 있음에도 모두를 반환 할 수 밖에 없는 상태가 되기 때문에 나눌수있다.

 

2. 용도의 차이

반환을 할때 모든 필드가 필요가 없을수도 있음에도 모두를 반환 할 수 밖에 없는 상태가 되기 때문에 나눌수있다.