❓ MVC 패턴이란?
애플리케이션을 모델, 뷰, 컨트롤러로 구분해 설계하는 소프트웨어 아키텍처 디자인 패턴으로, 선대 개발자들이 어떻게든 편하게 개발하려고 머리 굴리다가 만들어진 방법론 중 하나이다.
🧩 MVC 패턴의 구성요소
MVC의 핵심은 Separated Presentation으로, 프레젠테이션 로직(View, Controller)과 도메인 로직(Model)을 분리하자는 아이디어다.
이러한 생각에 따라 MVC 패턴은 다음 세 가지 컴포넌트로 구성된다.
Model
어플리케이션이 무엇을 할 것인지 정의하는 파트다.
데이터와 데이터 조작(비즈니스 로직)을 담당한다.
View
사용자에게 어떻게 보여줄지 정의하는 파트다.
UI를 통해 입력을 전달 받고, 업데이트된 데이터를 출력한다.
Controller
View와 Model의 중간 역할을 한다.
View로부터 전달받은 입력값을 검증하고 처리해 모델에 전달하며, Model에서 변경된 데이터를 다시 View에 전달한다.
📏 MVC 패턴을 잘 지키기 위한 규칙
- 모델은 컨트롤러나 뷰에 의존하면 안된다.
- 모델 내부에 컨트롤러 및 뷰와 관련된 코드가 있으면 안된다.- 뷰는 모델에만 의존해야 하고, 컨트롤러에는 의존하면 안된다.
- 뷰 내부에 모델의 코드만 있을 수 있고, 컨트롤러의 코드가 있으면 안된다.- 뷰가 모델로부터 데이터를 받을 때는 사용자마다 다르게 보여주어야 하는 데이터에 한해서만 받아야 한다.
- 컨트롤러는 모델과 뷰에 의존해도 된다.
- 컨트롤러 내부에는 모델과 뷰의 코드가 있을 수 있다.
- 뷰가 모델로부터 데이터를 받을 때는 반드시 컨트롤러에서 받아야 한다.
여기서 2번과 5번이 모순된다고 생각될 수 있는데, 다음과 같은 구조로 코드를 짜면 성립한다.
function controllerFunc() {
let value = modelValue;
viewFunc(value);
}viewFunc는 모델의 데이터를 인자로 받는(모델에 의존) 뷰의 함수다.
그리고 컨트롤러의 함수인 controllerFunc는 모델로부터 모델의 값인 modelValue를 가져와 viewFunc의 인자로 넣어준다.
⚠ 단점
UI 로직과 관련된 데이터의 경우, 어디에서 관리되어야 하는지 애매하다.
데이터를 관리하는 모델에서 관리하기에는 비즈니스 로직과는 상관이 없고, 프레젠테이션 로직에서 관리하자니 데이터를 관리할 명확한 규칙이 없다는 문제가 발생한다.
이러한 문제점을 해결하기 위해 MVP와 MVVM과 같은 다양한 디자인 패턴들이 등장하게 된다.
