요청과 응답으로 엔티티(Entity) 대신 DTO를 사용하자

https://tecoble.techcourse.co.kr/post/2020-08-31-dto-vs-entity/

요청과 응답으로 엔티티(Entity) 대신 DTO를 사용하자

 

 

그렇기 때문에 엔티티가 getter와 setter를 갖게 된다면, controller와 같은 비즈니스 로직과 크게 상관없는 곳에서 자원의 속성이 실수로라도 변경될 수 있다. 또한 엔티티를 UI계층에 노출하는 것은 테이블 설계를 화면에 공개하는 것이나 다름없기 때문에 보안상으로도 바람직하지 못한 구조가 된다.

 

 

이처럼 모든 API 요청과 응답에서 엔티티의 모든 속성이 함께 전송되기 때문에 당연히 속도도 느려질 수 밖에 없다.

 

물론 엔티티에서도 @JsonIgnore같은 어노테이션을 사용하면 화면으로 보내지 않을 속성을 지정할 수 있는데, 이 역시 근본적인 해결책이 될 수는 없다.

 

 

 

#JPA 순환참조

Post Entity를 그대로 반환하게 되면 Post가 참조하고 있는 Member Entity도 조회하게 되고, 이게 다시 Post를 참조해서 다시 Post Entity를 조회하게 되고, 이게 계속 반복되는 것이다.

 

 

#toEntity 메서드

는 DTO객체에서 만들자. Address toEntity(AddressRequest addressrequest){}

 

but DTO를 서비스단으로 넘긴다면?

 우선 서비스는 리포지토리를 DI(dependency injection)받아 사용하게된다. 영속성 계층과 엔티티를 주고받는 로직들이 대부분을 이루는것은 물론 하나의 서비스와 하나의 리포지토리가 대응되는 경우가 많다. 그런데 여기서 DTO라는 모호한 데이터(DTO가 어떤 데이터를 가지고있는지 상황에 따라 다를 수 있다) 객체를 받아서 사용한다는 점에서 해당 서비스의 역할이 불분명해지는것은 물론 다른 컨트롤러나 서비스에서 해당 서비스를 신뢰할 수 없는 경우가 생긴다.

 

엔티티의 변환작업을 다루는 별도의 유틸을 만들어 컨트롤러에서의 로직을 최소화한다.

서비스와 리포지토리 계층에선 DTO는 전혀 다루지 않고 엔티티만 다루며 모든 변환과정은 컨트롤러와 엔티티 변환 유틸에서 이루어진다.

 

 

=====

 

Exception 발생 위치??

Service?

https://anaog.tistory.com/7

권한(401)Authorization에 대한 검증은 컨트롤러, 유효성(404)Authentication 에 대한 검증은 서비스

이렇게 정할 수 있다. 

 

•  인증(Authentication)과 인가(Authorization)에 대한 개념의 차이와 의미에 대해 명확하게 인지하기
• 인증이란 서버에서 클라이언트가 누구인지를 확인하는 것을 의미한다.
  • 예를들어 클라이언트가 누구인지 확인하는 절차와 회원가입, 로그인 등이 이에 해당한다.
• 인가란 클라이언트가 처리하고자하는 작업에 대해 클라이언트가 해당 권한을 가지고 있는지를 의미한다.
  • 예를들어 게시글 수정과 삭제 같은 작업을 시도할 때 클라이언트가 해당 게시물에 대한 권한을 가지고 있는지 확인하는 것이 이에 해당한다.

로그인 관련인 @LoginRequired에 대한 인터셉터 부분 이므로 403 FORBIDDEN을 401 UNAUTHORIZED 로 교체

 

결론 : 게시물 수정, 삭제, 등록 권한 가지고 있는가 ? -> 인가(Authorized)

          로그인 등 인증 실패 -> 인정(403 Forbidden