[JPA] Entitiy 대신 ResponseDto,RequestDto 사용, 그 이유

V1 엔티티를 Request Body에 직접 매핑

@PostMapping("/api/v1/members")
    public CreateMemberResponse saveMemberV1(@RequestBody @Valid Member member){
        Long id = memberService.join(member);
        return new CreateMemberResponse(id);
    }

문제점

• 엔티티에 프레젠테이션 계층을 위한 로직이 추가된다.
• 엔티티에 API 검증을 위한 로직이 들어간다(@NotEmpty 등)
• 실무에서는 회원 엔티티를 위한 API가 다양하게 만들어지는데, 한 엔티티에 각각의 API를 위한 모든 요청 요구사항을 담기는 어렵다.
• 엔티티가 변경되면 API 스펙이 변한다.

 

결론

API 요청 스펙에 맞춰 별도의 DTO를 파라미터로 받는다.

 

V2 엔티티 대신에 DTO를 RequestBody에 매핑

@PostMapping("/api/v2/members")
    public CreateMemberResponse saveMemberV2(@RequestBody @Valid CreateMemberRequest request){
        Member member = new Member();
        member.setName((request.getName()));

        Long id = memberService.join(member);
        return new CreateMemberResponse(id);
    }

• CreateMemberRequest를 Member 엔티티 대신에 RequestBody와 매핑한다.
• 엔티티와 프레젠테이션 계층을 위한 로직을 분리할 수 있다.
• 엔티티와 API 스펙을 명확하게 분리할 수 있다.
• 엔티티가 변해도 API 스펙이 변하지 않는다.

 

참고 : 실무에서는 엔티티를 API 스펙에 노출하면 안된다

 

 

TIL

최근 진행했던 프로젝트에선 requestDto,resposeDto 사용하는 이유를 자세히 알지 못해서, 

계속된 DTO 생성의 번거로움을 느끼고 어느 부분에선 Entity를 사용하여 프로젝트를 진행했다

그러니 나중에 Entity별로 꼬여서 해결방안을 찾다가 Dto를 사용했더니 문제가 해결되었던 기억이 있다.

최근 JPA 강의를 들으며 공부를 하면서 requestDto,responseDto의 중요성을 알게 되었다.