MVC 패턴(Model-View-Controller Pattern)

MVC패턴은 디자인 패턴 중 하나이다

애플리케이션을 세 가지 주요 컴포넌트로 분리하여 관리하고 이를 통해 코드의 재사용성, 유지보수성, 확장성을 높인다

구조는 쉽게 말하면, View 단과 Model 단이 있고 그 사이에 Controller 단이 껴서 중재하는 구조이다

 

MVC 패턴의 구성 요소

1. Model (모델)
   • 역할: 애플리케이션의 핵심 데이터와 비즈니스 로직을 담당한다. DB와의 상호작용, 데이터의 생성, 수정, 삭제 등의 작업을 수행
   • 예시: 사용자 정보, 상품 목록, 주문 내역 등 실제 데이터와 관련된 부분
2. View (뷰)
   • 역할: 사용자에게 데이터를 표시하는 UI 역할을 한다. 사용자 인터페이스 요소(HTML, CSS, JavaScript 등)를 생성하여 데이터를 시각적으로 표현
   • 예시: 웹 페이지의 템플릿, 대시보드, 폼 등
3. Controller (컨트롤러)
   • 역할: 사용자의 입력을 처리하고, 이를 바탕으로 모델과 상호작용한 후, 적절한 뷰를 선택하여 응답을 반환한다. 사용자 요청을 해석하고, 모델과 뷰 사이의 흐름을 제어
   • 예시: 사용자가 버튼을 클릭했을 때 이를 처리하여 데이터를 업데이트하고, 업데이트된 데이터를 뷰에 반영

 

MVC 패턴의 동작 흐름

1. 사용자 요청: 사용자가 웹 애플리케이션에서 특정 작업(예: 페이지 방문, 폼 제출)을 요청
2. 컨트롤러 처리: 컨트롤러가 이 요청을 받아 적절한 모델을 호출하여 필요한 데이터를 가져오거나 처리
3. 모델 업데이트: 모델이 데이터베이스와 상호작용하여 데이터를 조회, 수정, 삭제 등의 작업을 수행
4. 뷰 선택 및 렌더링: 모델에서 처리된 데이터를 기반으로 컨트롤러가 적절한 뷰를 선택하여 사용자에게 응답을 반환
5. 사용자에게 응답: 최종적으로 사용자는 업데이트된 뷰를 통해 결과를 확인

예시) 사용자가 로그인 페이지에서 로그인 버튼을 클릭한 상황

1. 사용자 요청: 로그인 폼 제출
2. 컨트롤러: 로그인 요청을 받아 사용자 인증을 위해 모델에 요청
3. 모델: 데이터베이스에서 사용자 정보 조회 및 인증 처리
4. 컨트롤러: 인증 결과에 따라 성공 시 대시보드 뷰를, 실패 시 오류 메시지를 포함한 로그인 뷰를 선택
5. 뷰: 사용자에게 적절한 응답 페이지를 렌더링하여 표시

 

MVC 패턴의 장점

• 분리된 관심사: 각 컴포넌트가 독립적으로 동작하므로, 특정 부분을 수정할 때 다른 부분에 영향을 최소화할 수 있다
• 재사용성: 모델과 뷰가 분리되어 있어, 동일한 모델을 여러 뷰에서 재사용할 수가 있다
• 유지보수 용이: 구조가 명확하게 분리되어 있어 코드의 유지보수와 확장이 용이하다
• 협업 효율성: 개발자와 디자이너가 각각 컨트롤러/모델과 뷰를 독립적으로 작업할 수 있어 협업이 효율적이다

 

 

요즘 개발 트렌드는 프론트엔드 개발자가 View 단을 맡아서 진행하고 백엔드 개발자가 Model 단과 Controller 단을 맡아서 진행한다

 

 

 

[실전: MVC 패턴을 지키는 규칙 5가지]

1. Model은 Controller와 View에 의존하지 않아야 한다 (= Model 내부에 Controller와 View에 관련된 코드가 있으면 안 된다)

Model 클래스에 Controller와 View의 클래스를 import 해서 사용하면 안 된다

Model에는 깔끔하고 정제된 데이터만 있어야 한다

 

 

2. View는 Model에만 의존해야 하고, Controller에는 의존하면 안 된다 (= View 내부에 Model 코드만 있을 수 있고, Controller의 코드가 있으면 안 된다)

Model에 있는 클래스를 View단에서 사용할 수 있다

하지만 Controller에 있는 클래스는 안된다

 

3. View가 Model로부터 데이터를 받을 때는, 사용자마다 다르게 보여주어야 하는 데이터에 대해서만 받아야 한다

쉽게 얘기해서 배달 어플 주소지 입력창을 예로 들면, 형식적인 UI는 받으면 안 되고 사용자 개개인마다 다른 주소지 데이터만을 Model로부터 받아야 한다

 

4. Controller는 Model과 View에 의존해도 된다 (= Controller 내부에는 Model과 View의 코드가 있을 수 있다)

어떻게 보면 당연하다! Controller는 Model과 View의 중재자 역할이다

 

5. View가 Model로부터 데이터를 받을 때, 반드시 Controller에서 받아야 한다

 

 

 

 

 

 

 

참고 및 출처: 스프링 공식 깃허브, [10분 테코톡] 제리의 MVC 패턴