[백엔드/Spring] - mvc 패턴과 스프링 mvc
목차
1.MVC(Model-View-Controller) 패턴?
2. 스프링 mvc 동작과정
3. 실제 프로젝트와 비교
MVC(Model-View-Controller) 패턴?
MVC 패턴은 디자인 패턴 중 하나로, 소프트웨어를 세 가지 구성 요소(Model, View, Controller)로 분리하여 개발하는 디자인 패턴이다. Model, View, Controller는 각각 아래와 같은 역할을 수행한다.
1. Model
- Model은 비즈니스 로직과 데이터를 나타낸다. Model은 보통 데이터베이스와 직접적으로 상호작용하거나, 외부 서비스와 통신하여 데이터를 가져오거나 처리하는 역할을 한다.
2. View
- View는 사용자 인터페이스를 나타낸다. 실제 사용자에게 보여지는 화면을 의미하며 사용자의 요청을 컨트롤러로 전달하는 역할도 한다.
3. Controller
- Controller는 모델과 뷰 사이에서 중간자 역할을 수행한다. 사용자의 요청을 받아 해당 요청을 정해진대로 처리하고 사용자에게 적절한 응답을 제공한다.
MVC의 세가지 구성요소는 위와 같은 역할을 수행한다고 볼 수 있다. 처음에는 너무 추상적인 이야기라서 이해가 잘 되지 않았다. 사실 그냥 쉽게 얘기하자면 Model은 DTO, DAO와 같은 데이터 전달을 위한 클래스를 의미한다. View는 프론트엔드 단에서 사용자에게 직접 보여지는 화면을 의미하고, 컨트롤러는 '@RequestMapping'과 같은 Annotation에 의해 매핑되어 사용자 요청을 처리하는 핸들러를 호출하는 역할을 한다. 이에 대해서는 이 글의 마지막 목차인 실제 프로젝트와 비교에서 좀 더 설명되어 있다.
스프링 mvc 동작과정
스프링 또한 이러한 mvc 패턴을 지키며 동작한다. 스프링의 동작과정은 이러한 mvc 패턴에 기반하며 내부적으로는 아래와 같이 동작한다고 볼 수 있다.
클라이언트로부터 요청이 들어오게 되면 DispatherSrvlet은 해당 요청을 처리할 수 있는 핸들러(컨트롤러)를 조회한다. 요청을 처리할 수 있는 핸들러(url 경로가 일치하는 컨트롤러)를 찾으면 해당 핸들러를 처리(실행)할 수 있는 핸들러 어댑터를 찾아 핸들러를 호출 시킨다.
그 후 핸들러 어댑터는 요청의 처리 결과를 ModelAndView 객체 형태로 반환하고 ViewResolver를 통해 클라이언트에게 전달할 View 객체를 반환한다.
위의 그림을 통해 이해하자면 스프링 mvc는 이런식으로 동작한다고 이해할 수 있다. 물론 무조건 이런식으로 동작한다는 얘기는 아니다. 아래의 질문글을 확인하자.
@ResponseBody인 경우의 실행흐름이 궁금합니다. - 인프런
안녕하세요. 항상 좋은 강의 감사합니다.다름이 아니라 제가 정확히 이해가 안 가는 부분이 있어서 질문드립니다.@responseBody 애노테이션이 붙은 컨트롤러의 메서드는 다음과 같이 실행된다고 이
www.inflearn.com
굳이 스프링에서 프론트엔드(View)를 처리하지 않고 별도의 프론트엔드 서버를 운용하거나 단순한 rest API 서버로만 운용하는 경우 스프링에서 View 객체를 생성해야할 필요가 없는데, 그 경우에는 View 객체 생성이 생략되고 http 응답 메시지를 생성하여 클라이언트 요청을 처리하기도 한다.
사실 프론트엔드의 처리는 대부분 따로 운용하기에 위와 같은 경우가 훨씬 많다. 스프링 mvc 구조를 익히면서 이 부분이 많이 아리송했는데 위와 같은 원리로 동작한다고 하니 꼭 기억해두어야 할 듯하다.
실제 프로젝트와 비교
마지막으로 이전에 실제로 진행했던 팀 프로젝트와 이번에 정리한 mvc 패턴의 이론적인 내용이 적용이 되었는 지 점검을 해보려고 한다. 아래의 사진을 보자.
Model
- repository에는 jpa를 활용하여 실제 db(mysql)과 연결하여 사용할 클래스들을 정의하였다. 그리고 그 데이터들을 백엔드 서버내에서 다루기 위해 dto 패키지에 데이터를 담을 모델 클래스들을 선언하여 클라이언트 응답에 사용하거나 따로 연산하는데에 사용하였다.
View
- 화면 처리는 프론트엔드 서버를 따로 운용하였다. 프론트엔드를 담당하는 팀원이 react를 이용하여 작성해주었고, 프론트와 백엔드 사이의 통신은 axios 라이브러리를 통해 처리해주었다.
Controller
- controller 패키지에는 경로에 따라 다른(rest) 요청을처리 해주는 컨트롤러(핸들러)들이 작성되어 있다. 그리고 일부 연산이나 따로 처리해야할 코드가 긴 로직들을 service 에 작성하여 코드를 정리하였다.
실제 진행했던 프로젝트와 비교를 해보면 위와 같고, 이론적으로 완전히 같지는 않지만 mvc 패턴을 유지하고 있다고 볼 수 있다. mvc 패턴에 대해 이론적으로만 배울 때는 너무 추상적인 내용으로 비춰져서 이해하기 어려웠는데 실제 프로젝트와 비교하고나서야 이해가 되었다.
mvc 패턴의 이론과 실제를 비교하고 나니 스프링이 참 설계가 잘된 프레임워크라고 생각한다. mvc 패턴을 지키기위해 특별히 많이 노력하지 않아도 mvc 패턴을 지키면서 프로젝트가 진행된다는 점도 놀랍다.