인프런 커뮤니티 질문&답변
작성한 질문수
컬렉션 조회에서의 데이터 조립
해결된 질문
작성
·
43
1
상품 목록 조회하는 부분이 지금은 응답과 테이블까지 필드가 모두 같은 형태라 간단한 것 같은데, 함께 보여줘야 할 데이터가 더 많은 경우에는 어떻게 처리하시나요?
예를 들어 상품 카드위에 세일 정보가 있을 수도 있고, 해당 상품이 현재까지 팔린 갯수를 카드 위에 표시해야 할 수도 있을 것 같습니다.
아래는 제가 생각해본 방안입니다.
서비스 컬렉션 조회 함수에서 함께 조립
단점: 단일 객체가 아닌 컬렉션이기에 데이터 매핑과 조립을 위한 로직이 굉장히 길어질 수 있다. (비즈니스 로직이 아닌 느낌), 또한 개념객체를 반환하는 것이 아닌 조립된 객체를 반환하기에 화면에 표시되어야 할 부가 데이터가 변할때마다 매번 다른 객체를 만들고 반환해주어야 한다.
컨트롤러에서 각각 조회 후 조립
단점: 컨트롤러에서 조회 후 조립을 한다면 ~ Service 등 부가 데이터를 조회하기 위한 함수가 있을 것이고, 이 함수 또한 반환하는 객체가 있을 것인데 그럼 이때 부가 데이터를 담고 반환하는 객체 또한 개념 객체로 생각해야 할까? (화면 구성에 따라 달라지는 데이터인데 내부 개념으로 정의해도 맞는 것일까?), 개념 객체가 아니라면, Service 레이어에 위치해도 되는 것일까?
적다보니 굉장히 길어진 느낌이네요...
강사님은 어떤 생각이신지 궁금합니다!
긴 글 읽어주셔셔 감사드립니다!
답변 2
0
안녕하세요 질문 감사드립니다
우선 적어주신 2가지 방법 모두 유효하다고 생각합니다!
이 경우들은 결국 같이 조회되는 부가 데이터의 성질과 본질을 생각해서 각가 대응하면 좋을 것 같습니다
가령 단순한 세일 정보라고 한다면 Product 자체적으로 데이터를 만들 수 있을 것 같구요 (정가 != 판매가 == 세일 표기)
현재까지 팔린 갯수 = Order 개념에 의존해야하므로 2번 전략으로 사용 가능 할 것 같습니다
대신 2번 전략을 유지한다했을때 컨트롤러가 너무 많은 책임과 역할과 로직을 수행할 수 있습니다
이렇다면 상위 컴포넌트를 구축해서 구현하는게 좋다고 생각합니다!
ex) ProductDisplayXXXXXX (WrapperService 건 facade 건 Decorator 건 이름은 정하기 나름이라고 봅니다)
저는 가급적 각 개념의 Service 는 본질적인 기능을 제공하는데 초점을 맞추는 편입니다!
(상품 id 목록의 주문 수를 가져와줘 => 주문 개념에 속할 수 있는 순수한 기능)
이 함수 또한 반환하는 객체가 있을 것인데 그럼 이때 부가 데이터를 담고 반환하는 객체 또한 개념 객체로 생각해야 할까? (화면 구성에 따라 달라지는 데이터인데 내부 개념으로 정의해도 맞는 것일까?), 개념 객체가 아니라면, Service 레이어에 위치해도 되는 것일까?
별개로 이 부분에대해서는 개념객체 일 수도 있고 아닐 수도 있습니다 (정의하기 나름이라고 봅니다)
주문 수 같은 정보는 중요하지는 않지만 부수적인 개념객체로 볼 수도 있고 그냥 단순한 데이터 객체로 생각해볼 수 있을 것 같습니다
할인에 대한 딱지는 만약 금액에 대한 정책이라면 Presentation Layer 에서 처리하는게 좋다고 봅니다!
다만 다른 정책에 대하여 할인 딱지를 보여줘야한다면 할인에 대한 개념이 필요한지 부터 검토해서 전략을 만들어볼 수 있을 것 같습니다!
모쪼록 답이 되었길 바랍니다! 추가 질문은 편하게 주세요!
완강까지 화이팅하시고 완강 후 수강평도 기대하겠습니다!
0
안녕하세요, 인프런 AI 인턴입니다. wheon06님.
상품 목록 조회에서 데이터 조립은 프로젝트의 구조와 요구사항에 따라 다르게 접근할 수 있는 복잡한 주제입니다. 아래는 두 가지 방안에 대한 간단한 설명과 각 상황에 맞는 적용 방안을 알려드리겠습니다.
1. 서비스 컬렉션 조회 함수에서 함께 조립
- 장점: 서비스 레이어에서 데이터를 조립하면 응답 객체를 일관성 있게 관리할 수 있습니다. 또한 한 곳에서 대부분의 작업이 이루어지므로 코드를 더 쉽게 추적할 수 있습니다.
- 단점: 서비스 레이어에 업무 로직이 복잡하게 얽히게 되면 수정이 어렵고 가독성이 떨어질 수 있습니다. 또한 화면 구성의 변화에 따라 객체 구조를 반복적으로 수정해야 할 수 있습니다.
2. 컨트롤러에서 각각 조회 후 조립
- 장점: 컨트롤러에서 필요한 데이터를 개별적으로 가져와 조립하면, 서비스 레이어가 훨씬 깔끔해집니다. 이는 서로 다른 서비스와의 결합도를 낮출 수 있다는 장점도 있습니다.
- 단점: 컨트롤러에 비즈니스 로직이 혼재하면 코드 유지보수가 어려워질 수 있습니다. 또한 단일 책임 원칙(SRP)을 위반할 위험이 있습니다.
추천 방안
보통 실무에서는 DTO(Data Transfer Object) 패턴을 이용하여 해결하는 경우가 많습니다. 각각의 서비스는 자신이 책임지고 있는 도메인 객체를 반환하고, 컨트롤러에서는 이러한 객체들을 통합하여 화면에 적합한 DTO를 생성하는 방식입니다.
- DTO 사용:
- 각 서비스는 자신의 도메인에 맞는 서비스만 제공하고, 컨트롤러에서는 이를 이용하여 최종 응답 DTO를 조립합니다.
- 데이터 변경이나 새로운 필드 추가가 있을 경우 DTO와 이를 생성하는 컨트롤러 로직만 수정하면 되므로 관리가 용이합니다.
- 각 서비스는 자신의 도메인에 맞는 서비스만 제공하고, 컨트롤러에서는 이를 이용하여 최종 응답 DTO를 조립합니다.
마지막으로, 기존 학습자들의 경험을 공유한 것을 보면, 목록 조회에서 개념(도메인)객체를 반환할 때라는 질문에서도 비슷한 고민을 나눴습니다. 이를 참고하면 더 다양한 시각에서 이해를 넓힐 수 있을 것입니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.