[JPA] DTO 정의와 활용 범위

(※ 아래 글은 MVC 패턴을 먼저 숙지 하셔야 됩니다)

 

엔티티 객체(도메인 객체)는 DB table 그 자체입니다. 

따라서, 엔티티를 통째로 Veiw 에게 넘겨주면, password 와 같은 민감한 정보도 함께 넘어갑니다.

User.java (엔티티)

public class User {

    public Long id;
    public String name;
    public String email;
    public String password; //외부에 노출되서는 안 될 정보
    public DetailInformation detailInformation; //외부에 노출되서는 안 될 정보

    //비즈니스 로직, getter, setter 등 생략
}

UserController.java  (DB 정보를 통째로 넘김 ㅠ)

@GetMapping
public ResponseEntity<User> showArticle(@PathVariable long id) {
    User user = userService.findById(id);
    return ResponseEntity.ok().body(user);
}

 

DTO(Data Transfer Object) 는 이런 위험을 막기 위한 엔티티 객체의 분신이죠.

아래 UserDto 클래스를 보면, password 정보는 빠져 있는걸 볼수 있습니다.

Veiw 에게 넘게주는 정보를 custum 하는게 주 목적입니다.

UserDto.java

public class UserDto {

    public final long id;
    public final String name;
    public final String email;

    //생성자 생략

    public static UserDto from(User user) {
        return new UserDto(user.getId(), user.getName(), user.getEmail());
    }
}

UserController.java (여기서 엔티티 → DTO 전환)

@GetMapping
public ResponseEntity<UserDto> showArticle(@PathVariable long id) {
    User user = userService.findById(id);
    return ResponseEntity.ok().body(UserDto.from(user));
}

 

아래 그림은 일반적인 서버단 레이어 설계입니다.

지금까지는 1번 공간에서 DTO ↔ 엔티티간 변환 작업 이었습니다.

그런데 생각해보면, 1번 말고도 다른 위치에서도 이 작업이 가능합니다.

2번은 service 레이어에서 DTO 변환, 3번은 repository 레이어에서 DTO 변환을 나타내죠.

그럼 어디서 하는게 제일 적당할가요?

 

일단, 구루들의 주장에 repository 에서 사용은 없습니다.

controller 또는 service 중에 정해야 됩니다.

 

1. controller 에서 변환은 아래와 같은 문제점이 있습니다.

• Controller가 여러 Domain 객체들의 정보를 조합해서 DTO를 생성해야 하는 경우, 결국 Service(응용 계층) 로직이 Controller에 포함되게 됩니다.
• 여러 Domain 객체들을 조회해야 하기 때문에 하나의 Controller가 의존하는 Service의 개수가 비대해집니다.

2. 마틴 파울러는 Service 레이어란 어플리케이션의 경계를 정의하고 비즈니스 로직 등 도메인을 캡슐화하는 역할이라고 정의합니다. 즉, 도메인을 보호합니다. 엔티티 Model을 표현 계층에서 사용하는 경우 결합도가 증가하여, 도메인의 변경이 Controller의 변경을 촉발하는 유지보수의 문제로 이어질 수 있습니다.

 

※ 결론

내가 생각해도 DTO-Entity 간의 변환 위치는 Service 레이어가 맞는듯,,,

유지 보수도 더 좋은것 같다

 

 

※ 참고 문서

DTO의 사용 범위에 대하여