1-3. 회원 조회 API

조회 API는 테이블 변경 없으므로 none으로 변경. -> 한번 데이터 넣어두면 계속 테이블 쓸 수 있음.

 

서버 껐다 켜도 데이터 남아있다.

왜 이렇게 하냐면 -=> 조회 개발할 때 반복적으로 데이터 넣기 귀찮음.

 

 

v1의 멤버조회API : 

이렇게 나온다. -> 회원정보만 원하는데 불필요한 orders 까지 반환된다. -> 엔티티정보가 외부에 노출된다.

 

@JsonIgnore 쓰면 orders 빠지긴함. -> 근데 다른 API 에서 문제가됨. (다양한 반환 타입 필요할 텐데 이러면 orders 는 다 빠지게 됨.) -> 엔티티에 화면을 뿌리기위한 로직이 들어가 버렸다. (역할 여러개.) = 엔티티에 프레젠테이션계층의 로직이 추가되었다.

 

=> 이렇게 되면 API 스펙, 화면에 대한 부분들이 엔티티에 들어가면 (엔티티로 의존관계가 들어와야하는데 반대로 엔티티에서 의존관계가 나가는 상태 -> 양방향의존 걸리면서 애플리케이션 수정 어려워짐 ) -> 이해안됨.

 

=> 전과 비슷한 이유로 (엔티티 바뀌면 API구조가 바뀌는 경우 -> 굉장히 심각한 문제) 

 

=> 결론 : 엔티티 직접 반환하지마라.

 

하나하나 이해하라.

조회로직 하나하나를 대응할 수 없다.

 

 

# 진짜 세심한 문제점 :

 

지금 응답을 보면 [ ] 로 감싸져 있다. -> array (이것도 JSON스펙이다. -> 여러JSON 묶으면 [ ])

 

-> 하지만 여기에 만약 count 같은 걸 추가해 달라고 한다. ->

이런 식으로 -> JSON은 [ ] 안에 { } 만 있는 구조인데  저렇게 쓰면 JSON 깨져버림.

 

[ ] 안에 {},{},{} 로직.

이런 구조는 상관없다. 

 

 

# 결론

진짜 맛있는 코드 (잘 분석 해봐라) Result로 감싸는 이유, 이때 T가 무엇인지 중요.

진짜 맛있는 코드 (잘 분석 해봐라) Result로 감싸는 이유, 이때 T가 무엇인지 중요.

진짜 맛있는 코드 (잘 분석 해봐라) Result로 감싸는 이유, 이때 T가 무엇인지 중요.

진짜 맛있는 코드 (잘 분석 해봐라) Result로 감싸는 이유, 이때 T가 무엇인지 중요.

진짜 맛있는 코드 (잘 분석 해봐라) Result로 감싸는 이유, 이때 T가 무엇인지 중요.

 

 

이렇게 전체 배열로 안되고 "data" 로 해서 배열로 들어갔다. 지린다.... -> 이래야 JSON형식 깨지않고 유연한 유지보수

 

 

엔티티 바뀌어도 여기서 getName 이 getUsername 으로 바뀌는 정도 일 것이다. -> API 스펙이 바뀌진 않는다.

 

결국 API스펙이 DTO와 1:1 이된다. (노출 할 필드만 DTo에 정의)

 

이렇게 DTO에 count필드를 추가하고 생성자에 count만 추가하면 

이렇게 이쁘게 추가된다. (아까 설명했던 JSON 형식을 깨지 않는다.)

 

회원 조회 시 엔티티를 절대 외부에 반환하지 말자! -> 모두 DTO로 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

 

 

결론 : 파라미터를 받거나 외부로 반환할 때 절대로 엔티티를 사용하지마라. -> DTO로 바꾸어 사용.

이유는 위에서 언급.

 

 

결론 : 파라미터를 받거나 외부로 반환할 때 절대로 엔티티를 사용하지마라. -> DTO로 바꾸어 사용.

결론 : 파라미터를 받거나 외부로 반환할 때 절대로 엔티티를 사용하지마라. -> DTO로 바꾸어 사용.

결론 : 파라미터를 받거나 외부로 반환할 때 절대로 엔티티를 사용하지마라. -> DTO로 바꾸어 사용.

결론 : 파라미터를 받거나 외부로 반환할 때 절대로 엔티티를 사용하지마라. -> DTO로 바꾸어 사용.

결론 : 파라미터를 받거나 외부로 반환할 때 절대로 엔티티를 사용하지마라. -> DTO로 바꾸어 사용.

결론 : 파라미터를 받거나 외부로 반환할 때 절대로 엔티티를 사용하지마라. -> DTO로 바꾸어 사용.

결론 : 파라미터를 받거나 외부로 반환할 때 절대로 엔티티를 사용하지마라. -> DTO로 바꾸어 사용.

결론 : 파라미터를 받거나 외부로 반환할 때 절대로 엔티티를 사용하지마라. -> DTO로 바꾸어 사용.

결론 : 파라미터를 받거나 외부로 반환할 때 절대로 엔티티를 사용하지마라. -> DTO로 바꾸어 사용.

결론 : 파라미터를 받거나 외부로 반환할 때 절대로 엔티티를 사용하지마라. -> DTO로 바꾸어 사용.

결론 : 파라미터를 받거나 외부로 반환할 때 절대로 엔티티를 사용하지마라. -> DTO로 바꾸어 사용.

결론 : 파라미터를 받거나 외부로 반환할 때 절대로 엔티티를 사용하지마라. -> DTO로 바꾸어 사용.

결론 : 파라미터를 받거나 외부로 반환할 때 절대로 엔티티를 사용하지마라. -> DTO로 바꾸어 사용.

결론 : 파라미터를 받거나 외부로 반환할 때 절대로 엔티티를 사용하지마라. -> DTO로 바꾸어 사용.

 

 

실무에서는 여러 테이블 조인해서 API 만든다.

-> 복잡한 API 성능챙기면서 만들기.

-> 다음강의