[Spring] API 개발 시 Request는 DTO에 받아오자

API 서버를 개발할 때 Request를 받아올 DTO를 생성해서 사용하자✨

Entity

public class Member {
    private Long id;

    private String name;

    private Address address;
}

• 3개의 필드를 갖는 엔티티

Request를 엔티티에 받아오는 경우 (BAD)

 @PostMapping("/v1/posts")
    public Response saveMember1(@RequestBody @Valid Member member)
{
        Long id = memberService.join(member);
        return new Response(id);
    }

• Request Body를 그대로 Member 엔티티에 매핑하고, 그대로 로직이 실행된다 => 엔티티에 @NotEmpty와 같은 검증 로직 필요
• 같은 엔티티에 대해 여러 로직이 필요한데, 이때 문제 발생
  - (ID)만 넘겨주는 POST 요청, (ID, NAME)만 넘겨주는 POST 요청, 모두 넘겨주는 POST 요청 등...

  일반 로그인, 구글 로그인, 카카오 로그인 등 동일한 회원 객체에 대한 다양한 로직 필요

요청 1 : HTTP Body -> 엔티티
				  (로직1 실행)
요청 2 : HTTP Body -> 엔티티
				  (로직2 실행)

엔티티가 변하면 API 스펙이 변한다!!
=> 엔티티가 로직을 갖고 있는 것이 아니라,
Request 별로 필요한 DTO를 생성하고 Request를 담아서 로직 실행

Request를 DTO에 받아오는 경우 (GOOD)

@PostMapping("/v2/posts")
public Response saveMemberV2(@RequestBody CreateMemberRequest request) {
    Member member = new Member();
    member.setName(request.getName());
    Long id = memberService.join(member);
    return new Response(id);
}

// DTO 객체
static class createMemberRequest {
    @NotEmpty
	private String name;
}

요청 1 : HTTP Body -> DTO 객체1 -> 엔티티
					(로직 실행)
요청 2 : HTTP Body -> DTO 객체2 -> 엔티티
					(로직 실행)

DTO란?

DTO (Data Transfer Object)
계층 간 데이터 전송을 위한 객체

• 로직을 갖고 있지 않은 순수한 데이터 객체
• Request용 DTO의 경우 @NotEmpty, @Size 등 어노테이션을 이용해 입력값을 검증할 수 있음
• Response DTO의 경우 Setter 사용하지 않고, 생성자를 통해 값을 할당

정리

• Entity는 절대 클라이언트에 노출시켜선 안된다
• Entity에는 도메인 로직만 구현하고, View와 관련한 로직은 구현하지 않는다.