작성
·
430
2
안녕하세요!
Response 클래스가 필요하다는 것은 잘 이해했습니다.
그런데 Response 클래스를 서비스가 아닌 컨트롤러에서 변환하는 것은 어떻게 생각하시나요?
서비스에서는 리포지토리에서 엔티티를 반환받아서, 컨트롤러에 엔티티를 전달하고 컨트롤러에서 엔티티를 Response로 변환하여 리턴하는 식으로 현재 개발을 해봤는데요.
생각을 좀 해보니까, 엔티티를 Response로 변환하는 것을 비즈니스 로직이라고 생각하면 서비스에 포함시키는게 맞는것 같고..
뭔가 Response는 화면UI 에 따라 자주 변할 수 있는 가능성이 많으니까 차라리 서비스는 항상 엔티티만 리턴하고 컨트롤러에서 UI에 맞게 변환만 해서 반환하는 것도 나쁘지 않다고 생각했는데요.
혹시 어떤 방법이 실무에서 자주 쓰이는지 궁금합니다.
답변 2
2
안녕하세요. 호돌맨입니다.
질문을 남겨주셔서 감사합니다.
현재 강의는 최대한 쉽게 설명 드리기 위해 서비스에서 response를 반환하고 있습니다.
제가 잘 개발하고자 한다면 Service는 web영역으로 구분 할 수 있는 Response를 알지 못하도록 개발할 것 같습니다.(그 반대로 Request관련 클래스도 Service가 모르게 할 것 같습니다.)
Service는 entity를 별도의 클래스(DTO)로 변환하여 Controller로 넘길것 같습니다. 그리고 그 DTO를 Controller에서 받은 뒤 Response 클래스로 변환 할 것 같습니다.
서비스에서 entity를 직접 Controller로 넘기지 않는 이유는 Response로 변환할 때 뒤 늦은 entity의 참조를 방지하기 위해서 입니다.
감사합니다.
0
안녕하세요! 강의 재미있게 듣고 있습니다!
호돌맨님 답변중에
서비스에서 entity를 직접 Controller로 넘기지 않는 이유는
Response로 변환할 때 뒤 늦은 entity의 참조를 방지하기 위해서 입니다.
-> 이 이유는 연관관계가 있는 엔티티를 조회 시 지연로딩 때문이고 osiv를 false로 사용하기 때문일까요?