728x90
- 문제점
- 엔티티에 프레젠테이션 계층을 위한 로직이 추가된다.
- 기본적으로 엔티티의 모든 값이 노출된다.
- 응답 스펙을 맞추기 위해 로직이 추가된다. (@JsonIgnore, 별도의 뷰 로직 등등)
- 실무에서는 같은 엔티티에 대해 API가 용도에 따라 다양하게 만들어지는데, 한 엔티티에 각각의 API를 위한 프레젠테이션 응답 로직을 담기는 어렵다.
- 엔티티가 변경되면 API 스펙이 변한다.
- 추가로 컬렉션을 직접 반환하면 항후 API 스펙을 변경하기 어렵다.(별도의 Result 클래스 생성으로 해결)
- 반환 객체가 배열 형태이기 때문에, 만약 Count라는 변수를 추가할 경우 확장이 어렵다.
- WHY? 배열에는 같은 스펙을 데이터가 들어가야 되므로 count가 들어가면서 깨지게 된다.
- 따라서 확장이 유연하게 툴을 만들어야 된다.
- ex) count : 4, data_list : [ list데이터들....]
- 결론
- API 응답 스펙에 맞추어 별도의 DTO를 반환한다
참고: 엔티티를 외부에 노출하지 마세요!
- 실무에서는 member 엔티티의 데이터가 필요한 API가 계속 증가하게 된다. 어떤 API는 name 필드가 필요하지만, 어떤 API는 name 필드가 필요 없을 수 있다. 결론적으로 엔티티 대신에 API 스펙에 맞는 별도의 DTO를 노출해야 한다.
회원 조회 V2
- Count와 변수가 추가되어도 확장이 유연하다.
728x90
'실전! 스프링 부트와 JPA 활용2(API 개발과 성능 최적화)' 카테고리의 다른 글
| Ch03. API 개발 고급(지연 로딩과 조회 성능 최적화) - 간단한 주문 조회 V2(Entity -> DTO로 변환) (0) | 2021.12.20 |
|---|---|
| Ch03. API 개발 고급(지연 로딩과 조회 성능 최적화) - 간단한 주문 조회 V1(엔티티를 직접 노출) (0) | 2021.12.20 |
| Ch02. API 개발 고급(준비) - API 개발 고급 소개, 조회용 샘플 데이터 입력 (0) | 2021.12.20 |
| Ch01. API 개발 기본 - 회원 수정 API (0) | 2021.12.19 |
| Ch01. API 개발 기본 - 회원 등록 API (0) | 2021.12.19 |