1. 등록, 수정, 조회 공통
1) 엔티티를 절대 Response 하지 마라!
[문제점 1] : 순환 참조 발생
※ 현재 코드와는 상관 없는 예시 사진입니다. 출처
만일 양방향관계를 갖고 있는 엔티티를 그대로 반환할 경우, 순환 참조가 발생해
stackoverflow에러가 발생 하게 된다.
[문제점 2] : 엔티티의 내부 구조 유출 및 보안 문제
현재의 경우 저장에 성공한 회원의 id 만 반환하고 싶은데 엔티티 전체를 반환하게 됨으로써 보이고 싶지 않은 데이터(이름, 주소 등)까지 전부 보여주게 된다.
대안책 : 엔티티 대신 "response" 전용 DTO를 하나 만들어라!
DTO
컨트롤러
API response
필요한 필드만 따로 추출하여 DTO에 주입한다음 반환해주면된다.
2) 엔티티로 절대 Request 받지 마라!
문제점 1 : 유효성 검증 로직이 엔티티에 반영이 되버린다.
만일 회원가입을 할 때 어떤 로직에서는 이름을 반드시 가입해야하는데, 다른 로직에서는 그저 선택사항일 뿐인경우 경우, 엔티티 객체는 하나이기 때문에 두 경우가 공존 할 수가 없다.
문제점 2 : 조금씩 다른형태의 다양한 Request가 들어올때 대응이 안 된다.
회원가입의 경우, 간편 회원가입, 이메일 가입, SNS 가입 등등 다양한 형태로 가입을 하게 되는데 이때 과연
Member엔티티 하나로 모든 Request를 커버할 수 있을까? 불가능하다.
대안책 : 엔티티 대신 "request" 전용 DTO를 하나 만들어라!
DTO
컨트롤러
DTO로 데이터를 받은다음, 엔티티를 생성해 그곳에 데이터를 옮겨 담는다.
2. 조회
컬렉션 타입으로 response 하지 말아라!
문제점 : 확장성이 매우 떨어진다
컬렉션의 경우 객체와 달리 다른 타입의 데이터를 저장 할 수 없다. 그냥 객체라면 필드만 하나 추가해서 다른 타입의 데이터를 받을 수 있지만 컬렉션은 그게 불가능하다.
예를 들어 클라이언트로부터 전체회원 목록외에 전체 회원 수도 같이 보내달라는 요구사항이 들어왔다고 가정하자.
현재 API는 MemberDto 타입의 컬렉션으로 반환을 하고 있기 때문에, int 타입의 회원수도 같이 보내려면 새로운 컨트롤러 메서드를 만들던가 API 스펙을 수정할 수 밖에 없다.
대안책 : 컬렉션을 객체로 감싸서 response해라
필드를 가질 수 없는 컬렉션의 단점을 보완하고자 컬렉션을 포함하고 감싸는 Result 클래스를 만들어준다. 그러면 이제 부터는 클라이언트의 추가 요청사항을 보다 손쉽게 반영할 수 있는데 위와 같이 Result 의 필드에 "전체 회원 수" 를 저장할 변수(count)를 추가만 해주면 된다.
