1-1. 회원 등록 API, 1-2. 회원 조회 API

원래 MPA -> SPA 로 가는 추세. -> MSA로 가는 추세. ( API통신 정말 많음 )

보통 이런식으로 SSR 하는 컨트롤러는 controller 에 놓고 CSR 하는 컨트롤러는 api에 놓는다.

-> 예외처리를 보통 패키지 단위로 하기 때문에 ( controller, api는 공통 에러 처리가 너무 다르다. )

-> 템플릿엔진은 공통에러화면(html) 이 나와야 하지만 api는 공통 에러 JSON이 나가야함.

-> 패키지 분리 후 따로 예외 처리

api 폴더의 컨트롤러는 Api잘 붙임. ex) MemberApiController

id는 @GeneratedValue 이므로 안 보내줘도 됨.

-> name, address 중 아무거나 보내도 됨. 안보내도됨. ( 왜냐 -> 제약이 없어서 )

---

=====

1. 엔티티에 제약조건(@NotEmpty ) 걸음 -> 프레젠테이션계층을 위한 검증 로직이 엔티티에 들어가게 된다.

2. 만약 Member 엔티티의 name 이 username으로 바꾼다고 할 때 API 스펙 자체가 바뀌게 됨.

-> 엔티티를 손댔을 때 API 스펙이 바뀌는게 문제 ( 엔티티는 여러군데에 쓰여서 바뀔 확률이 높다. )

3. 결론 : API 스펙을 위한 별도의 DTO를 만들어야함.

(여러 DTO가 필요한 경우가 많다. ( ex) 회원가입종류(폼마다 입력필드 다름) ) -> 이걸 엔티티 하나로 다 받을 수 있을까? -> 안됨. -> DTO 각각 만들어서 받자. )

결론 : API 만들 때는 엔티티를 파라미터로 받지마라. 엔티티 외부노출금지

CreateMemberRequest 라는 DTO 만들어서 JSON 받음.

V2 장점 : 엔티티 필드 만약 name -> username 바뀌어도 저것만 setUsername으로 바꾸면 API 는 영향 없음.

장점 2. : validation 할 때도 각 API에 맞게 해줄 수 있다. -> DTO만 까보면 API 스펙 유추 가능

장점 3: 엔티티와 API스펙을 분리할 수 있다. (이해 안되면 계속 봐라.)

=====================================

1-2. 회원 수정 API

영한님은 엔티티에는 @Getter 정도만 쓸 정도로 제한적으로 사용, DTO는 막 씀(데이터 왔다갔다만 해서(비지니스로직이 있는 것도 아님.))

!!!!!!!!!!!!!!!!!!!!!!!!!!! 밑 사진 JPA 읽어보기. 영속상태 -> 더티체크 중요!!!!!!!!!!!!!!!!!!!!!!!!!!!!

#@#@#@## 중요!!!!!!!!!!!

여기서 MemberService 의 update에서 리턴으로 member를 넘겨도 되지만 영속상태가 끊긴 Member 객체가 넘어간다. ( 왜인지 모르면 JPA 다시 들어라 ) -> 영한님 스타일 : 커맨드와 쿼리를 철저히 분리한다.

-> update 라는 건 entity를 쫙 바꾸거나 하는 변경성 메서드이다. -> 여기서 id를 가지고 member를 조회하는 꼴이 된다. (커맨드와 쿼리가 같이 있다.?(이해안됨)) ->

update는 그냥 여기서 끝내버린다. -> 아니면 id 값 정도만 반환. (이건 커맨드)

이렇게 따로 조회 해줌. (커맨드와 쿼리를 분리)

쿼리 쭉 나가있다.

Develop