投稿した質問数 1

0

안녕하세요 강의 들어주시고 질문 남겨주셔서 감사합니다.

먼저 강의에선 편의를 위해 dto로 통일하여 사용하였지만 실무에선 말씀주신 것 처럼 요청에 따라 Request를 분리합니다

이유는 여러가지가 있겠지만 Request 안에서 요청에 대한 검증이나 정규식등을 활용해 정상적인 입력값인지 판단하기도 하고 내부 로직을 넣어서 필요시 사용하는 경우들이 많아 말씀주신 것 처럼 분리해서 사용한다 알아두시면 될 것 같습니다.

0

안녕하세요, 인프런 AI 인턴입니다. 정인호님.
풀스택 개발 강의를 열심히 진행 중이시군요! REST API 설계에서 객체 변환 및 사용에 관한 중요한 질문을 주셨네요.

Springboot 프로젝트에서 Controller와 Service 계층 사이에 DTO(Data Transfer Objects)를 다르게 사용하는 것이 일반적입니다. 이렇게 계층을 분리하면 각 계층의 책임을 명확히 할 수 있고, 데이터의 캡슐화를 이룰 수 있습니다. 이를 통해 하나의 계층에서의 변경이 다른 계층에 영향을 미치지 않도록 하여 유연성과 유지보수성을 확보할 수 있습니다.

다만, 말씀하신 것처럼 DTO와 결과 객체를 매번 새로 정의하면 많은 변환 작업이 필요하기 때문에, 이는 실무에서 과도한 복잡성을 초래할 수 있습니다. 이 문제를 해결하기 위해 몇 가지 실무에서 자주 사용하는 방법이 있습니다:

1. 공통 DTO 사용: 가능하다면, 여러 API에서 공통으로 사용할 수 있는 DTO를 정의하여 중복을 최소화하는 방법이 있습니다. 이렇게 하면 불필요한 객체 증가를 방지할 수 있습니다.

2. MapStruct 등 Mapper 활용: 객체 간 변환 작업을 보다 쉽게 할 수 있도록 다양한 라이브러리(MapStruct, ModelMapper 등)를 활용하여 변환 과정을 자동화할 수 있습니다. 이는 코드의 간결함을 유지하며, 변경이 있을 때 쉽게 대응할 수 있는 장점이 있습니다.

3. 객체의 재사용: 비슷한 필드를 가지는 객체들은 재사용하거나 필요에 따라 조합해서 사용할 수 있도록 설계합니다.

유사한 주제에 대한 기존의 입장을 참고하실 수 있는 게시물을 소개합니다:

• “DTO와 Entity의 구분 사용이 반드시 권장되는가?”
  

이 링크에서는 DTO와 엔티티 설계에 관한 다양한 논의가 이루어져 있으니 참고하시면 도움이 될 것입니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.