모델의 역할과 계층 분리에 대한 이해 차이 + 추가질문

스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술

MVC 패턴 - 개요

해결된 질문

작성

수정됨

안녕하세요, 강의를 들으면서 궁금한 점이 있어 질문드립니다.

강의에서는 모델을 컨트롤러와 뷰 사이에서 데이터를 전달하는 객체로 설명하면서, 컨트롤러는 비즈니스 로직을 직접 수행하기보다는 서비스와 리포지토리에 이를 위임해야 한다고 말씀해주셨습니다.

그런데 제가 기존에 알고 있던 개념은 조금 달랐습니다. 모델은 일반적으로 데이터베이스의 테이블을 표현하고, 컨트롤러가 요청을 받아 모델에 명령을 내리면, 모델이 데이터를 조작하거나 비즈니스 로직을 처리한 뒤 컨트롤러와 뷰에 변화를 알리는 구조라고 이해하고 있었습니다. 즉, 모델이 도메인 객체(DTO, 엔티티 등)와 함께 비즈니스 로직, 그리고 DB와의 실질적인 연결까지 담당한다고 생각해왔습니다.

따라서 강의에서 제시해주신 설명과 제가 알고 있던 개념 사이에 차이가 있는 것 같아 혼란스럽습니다. 혹시 제가 기존에 이해했던 방식이 잘못된 것인지, 아니면 단순히 접근 방식과 관점의 차이라고 봐야 하는지 조언 부탁드립니다.

spring mvc

답변 1

인프런 AI 인턴

안녕하세요, 인프런 AI 인턴입니다. 김민규님.

스프링 MVC와 관련된 여러분의 혼란스러움을 이해합니다. 사실, 말씀하신 모델의 역할과 계층 분리에 대한 이해는 문맥과 설계 철학에 따라 차이가 있을 수 있습니다.

MVC 패턴에서의 모델:
- 스프링 MVC에서 모델은 컨트롤러가 데이터를 뷰에 전달할 때 사용하는 객체로 설명되곤 합니다. 즉, 뷰에 전달될 데이터를 담고 있는 객체로 주로 사용됩니다.
도메인 객체:
- 일반적인 소프트웨어 설계에서 모델이 도메인 객체(DTO, 엔티티 등)를 포함하고 비즈니스 로직까지 처리한다고 설명할 수 있습니다. 이 경우, 모델은 데이터베이스와의 연결 및 비즈니스 로직을 처리하는 역할까지 포함할 수 있죠. 이는 도메인 주도 설계(DDD) 컨텍스트에서는 좀 더 강조됩니다.
서비스 레이어:
- 스프링 MVC 강의에서는 비즈니스 로직을 서비스 레이어에 위임하는 구조를 추천하며, 이는 소프트웨어의 유지보수성과 확장성을 높이는 데 도움을 줍니다. 서비스 레이어는 복잡한 비즈니스 로직을 처리하고, 데이터 계층(리포지토리 등)과 통신합니다.

관련해서 이미 다른 학습자들과 진행된 유사한 논의가 있어 링크를 첨부합니다. 도움이 되시길 바랍니다:

각 사례들은 특정 문맥에서 모델의 역할이 다르게 정의될 수 있음을 보여줍니다. 중요한 것은 적용하는 상황에 맞게 패턴을 유연하게 이해하고 활용하는 것입니다.

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

김민규

질문자

아키텍처 관점에서의 MVC 패턴에서는 모델이 비즈니스 로직과 도메인 객체를 포함하지만, Spring MVC에서는 뷰에 전달하는 객체를 모델로 간주한다고 이해할 수 있을까요?

김민규

질문자

추가로 궁금한 점이 있습니다.
REST API로 서비스를 설계할 경우, 사용자는 보통 프론트엔드를 통해 백엔드의 기능을 이용하게 됩니다. 이때 프론트엔드와 백엔드 각각에 MVC 패턴이 적용된다고 보아야 할까요, 아니면 두 계층을 합쳐 하나의 MVC로 이해해야 할까요? 또한 백엔드 측의 API를 Open API 형태로 외부에 공개한다면, 이것도 뷰로 간주할 수 있는지 궁금합니다.

인프런 커뮤니티 질문&답변

모델의 역할과 계층 분리에 대한 이해 차이 + 추가질문