인프런 커뮤니티 질문&답변
작성한 질문수
패키지를 분류하는 기준
작성
·
501
0
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.
1. 강의 내용과 관련된 질문을 남겨주세요.
2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.
(자주 하는 질문 링크: https://bit.ly/3fX6ygx)
3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.
(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)
질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.
=========================================
[질문 템플릿]
1. 강의 내용과 관련된 질문인가요? (예/아니오)
2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)
3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)
[질문 내용]
여기에 질문 내용을 남겨주세요.
안녕하세요!
패키지를 분류하는 기준은 Entity별로 패키지를 분류할 수 있고 or 강의에서 설명해주신 것 처럼 기능별로 패키지를 분류할 수 있을것 같습니다.
Entity별로 패키지를 분류한다면 -> member라는 패키지 안에 Member 엔티티 , MemberRepository , MemberService, MemberController 그리고 각종 MemberDto들을 저는 위치시켰습니다.
그리고 기능별로 패키지를 분류한다면 -> controller라는 패키지에 , 각 controller들을 모아놓았습니다.
이 두가지 방식이 있고 , 각 방식에 대한 장단점을 chatGPT에게 물어보았었는데요, 대규모 프로젝트에서는 entity 수가 많아지기 때문에 -> 기능별로 패키지를 분류하는 방법을 더 권장해주었습니다.
혹시 이러한 이유로 영한님께서도 기능별로 패키지를 분류하는 방식으로 강의를 진행하시는 건지 여쭤보고 싶습니다.
답변 1
1
안녕하세요. khd1692님, 공식 서포터즈 코즈위버입니다.
프로젝트를 진행하다 보면 하나의 서비스(가령, MemberService)가 여러 리포지토리 및 엔터티와 관계를 맺게 됩니다. (Member뿐 아니라 Point 나 Order 등) 이 경우 패키지와 패키지가 서로 얽히고 얽히는 관계선을 그리게 됩니다. 반면 Controller/Repository/Service/Entity 와 같은 패키지 형태를 가질 경우엔 관계가 Controller 에서 Service로, Service는 Entity로 향하는 비교적 단순한 형태를 취하게 됩니다.
추가로, Repository 에서 Entity로 관계선의 방향을 더 단순하게 갈 수 있습니다, 그러나 실제로 이렇게 분류하면 Service 에서 Entity를 직접 컨트롤할 수 없어 리포지토리가 엔터티를 DTO형태로 변환하고 Service는 DTO로 로직을 처리하는 등 코드가 불필요한 과정이 많다고 느낄 수 있습니다. 저의 경우에는 Service 에서 바로 Entity를 다루는 것이 의존 관계는 복잡하더라도 코드 자체가 간결하다고 생각하여 선호합니다 :)
감사합니다.
안녕하세요 khd1692님! 네 맞습니다 :)
크게 Controller / Service / Repository 로 나누어 구분합니다.
Entity / DTO / Enums 등은 인텔리제이에서 멀티모듈로 분리하여 참조하는 형태로 프로젝트를 진행하였는데, 적절한 분리는 프로젝트 상황에 따라 달라질 수 있을것 같습니다
그렇다면 결론적으로 Entity 별로 패키지를 분류하기보다는,
Controller / Service / Repository / Domain 형식으로 패키지를 분류하시는걸 더 선호하신다는 의미일까요?