두개를 비교하기 이전에 무엇인지 부터 알아보자
Entity
Entity는 실제 DataBase의 테이블과 1 : 1로 매핑되는 클래스로써, DB의 테이블 내에 존재하는 컬럼만을 속성으로 가지고 있다. Entity 클래스는 상속을 받거나 구현체여서는 안되며, 테이블 내에 존재하지 않는 컬럼을 가져서도 안된다
DTO
DTO(Data Transfer Object)는 데이터 전송 객체라는 의미를 가지고 있다. 즉, 각 계층간 데이터 교환을 위한 객체이다
▶ 분리한 이유
1. Entity의 보호
이게 굉장히 큰 이유중 하나라고 볼 수 있다. entity를 사용자에게 노출하게되면 원하지 않는 상황에서 자원의 속성이 변경될 가능성이 있다. 그리고 엔티티를 UI 계층에 노출하는 것은 테이블 설계를 화면에 공개하는 것이나 다름없기 때문에 보안상으로도 바람직 하지 못한 구조가 된다.
굉장히 중요한 말
DTO 는 setter 를 허용한다 하지만 Entity는 setter 를 사용해서는 안된다. 가끔 사용하는 경우도 생기지만 개인적으로 굉장히 불안한 상황이라고 생각한다. 때문에 다른 방법으로 Entity 값을 설정하는데 방법은 밑에서 설명하도록 하겠다
2. 화면에 필요한 데이터를 선별할 수 있다.
우리가 Entity는 DB와 직접적인 연결관계가 있다고 했다. 하지만 우리가 받아오는 데이터가 꼭 해당하는 Entity의 요소를 모두 가져올까? 그것이 아니다. 때문에 필요한 경우도 생기게 되는것이다. 이것은 생각보다 너무 많은 데이터를 가져오거나 더 적은 경우를 대비 할수 있다. 이것은 보안과 성능 면에서도 도움이 된다.
3. validation 코드와 모델링 코드를 분리할 수 있다
Entity 클래스는 DB의 테이블과 매칭되는 필드가 속성으로 선언되어 있고, 복잡한 비즈니스 로직이 작성되어 있는 곳이다. 그렇기 때문에 속성에는 DB와 직접적인 연결이 들어가는 JPA의 @Column, @JoinColumn, @ManyToOne, @OneToOne등의 모델링을 위한 코드가 추가된다.
만약 여기에 @NonNull, @NotEmpty, @NotBlank 등과 같은 요청에 대한 값의 validation 코드가 들어간다면 엔티티 클래스는 더욱 복잡해지고 그만큼 가독성이 저하되는것이다.
Setter 가 없는 Entity 에는 값을 어떻게 넣어서 DB에 전달할수 있을까
Builder 디자인 패턴 사용
디자인 패턴중 하나인 @Builder 를 어노테이션으로 사용하는 방법이다. 하지만 Builder 를 사용할때는 생성자가 꼭 있어야 한다. 물론 이것에 대한것은 JPA 를 다룰때 확실하게 나타나는데 그것은 나중에 꼭 따로 작성을 할 예정이다. 간단하게만 얘기 하자면 Builder는 생성자를 두고 그 값을 채워나가게 해주는 것이다 라고만 간단하게 설명하겠다.
Reference
📚 Dto와 Entity를 분리하는 이유, 분리하는 방법
작년에 프로젝트를 하면서 entity를 view에 그대로 반환했다가 Dto로 변환해야겠다는 생각이 들어서 바꿨었는데, Entity와 dto에 대한 내용을 블로그에 정리하면 좋을 거 같아 글을 쓰게 되었다. (일기
velog.io
'Spring > 🌲 Spring' 카테고리의 다른 글
🌲 Spring 의 @Scheduling (1) | 2024.04.20 |
---|---|
🌲 왜 Service 는 Impl을 구분하는 걸까? (0) | 2023.08.04 |
🌲 @NoArgsConstructor 와 @AllArgsConstructor 그리고 @RequiredArgsConstructor (0) | 2023.08.03 |
🌲 RestController 와 Controller 의 차이 (0) | 2023.08.03 |
🌲 Request 와 Response (0) | 2023.08.03 |