작성
·
339
2
영상에서 UI 계층 (Controller)에서 Member Entity Object를 생성해서 파라미터로 넘겨주어 Service 계층에서 회원가입 처리를 하도록 코딩을 하셨는데,
원래 UI계층에서 Entity Object를 생성해서 Service 계층에서는 응용서비스 관련 로직만 짜는게 맞는건가요?
아니면 앞 영상에서 말씀하셨던, 너무 "Controller -> service -> Repository 로만 구조를 가져가려면 딱딱하고 불편한 점이 있다,"라는 말씀을 하셨던 부분에 해당해서 다르게 코딩하신 건가요?
답변 2
3
안녕하세요. galid님 좋은 질문입니다.
도메인 객체의 범위를 어디까지 볼 것인가는 관점에 따라 다른데요. 어디서는 도메인 엔티티는 컨트롤러 계층에서 사용하면 안되는 아키텍처도 있고, 유연하게 컨트롤러에서 도메인 객체를 봐도 되는 아키텍처가 있습니다.
일반적으로 도메인 계층을 설계할 때는 컨트롤러에서도 도메인 계층을 의존하기 때문에 컨트롤러에서 엔티티를 생성해서 서비스 계층에 넘겨도 됩니다.
또는 객체 생성이 복잡한 경우 DTO나 파라미터를 서비스 계층에 넘기고 서비스 계층에서 엔티티를 생성해도 됩니다.
서비스 계층에서 도메인 객체(엔티티)를 받으면 서비스 계층의 재사용성이 증가되는 장점이 있지만, 반대로 엔티티의 생성 로직을 서비스 계층 외부에서 처리해야 하는 단점도 있습니다.
결국 정답이 있다기 보다는, 현재 내가 해결하야 하는 상황에 맞는 해결방법을 적절하게 선택하는 것이 중요합니다^^
감사합니다.
0
- 컨트롤러에서 엔티티 생성시 서비스 계층의 유연성 증가
- 하지만 서비스 계층이 아닌곳에서 엔티티 생성로직을 처리하게됨
친절한 답변 감사합니다. JPA 책을 통해서 공부하다가, 우연히 강좌를 찾게되어 영상을 통해 뵙게되니 더욱 반갑습니다. 결국 적절한 트레이드 오프가 필요한 부분이라는 말씀이신것 같습니다 감사합니다~