MVC 패턴 (Model-View-Controller Pattern)
1. MVC 패턴 (Model-View-Controller Pattern)
- 모델(Model), 뷰(View), 컨트롤러(Controller)로 이루어진 패턴
- 애플리케이션의 구성 요소를 세가지 역할로 구분하여 개발 프로세스에서 각각의 구성 요소에만 집중해서 개발함
2. 모델(Model), 뷰(View), 컨트롤러(Controller)
- 모델(Model)
- 애플리케이션의 데이터인 데이터베이스, 상수, 변수 등 > 데이터와 관련된 로직 담당
- 애플리케이션의 상태를 관리하고, 데이터를 처리하는 비즈니스 로직을 담당
- View나 Controller에서 요청을 처리 > 데이터를 저장, 변경 작업
- Model은 View나 Controller와 독립적 >> ***화면에 표시되는 방법이나 사용자 인터페이스와 무관
- ex) 사용자 데이터를 저장하는 데이터베이스 관련 작업
- ex) 상품의 가격을 계산하는 비즈니스 로직
- 뷰(View)
- 사용자가 볼 수 있는 UI요소들을 관리
- View는 Model로부터 데이터를 가져와 화면에 출력하지만, Model의 데이터를 변경이나 제어하지 않음
- View는 Controller로부터 이벤트(버튼 클릭, 화면 갱신 등)를 전달 받음 >> ***사용자와 상호작용
- ex) 웹 애플리케이션에서 HTML 페이지를 랜더링
- ex) 상세 페이지, 리스트, 차트 등 화면에 표시되는 부분
- 컨트롤러(Controller)
- 사용자 입력을 처리 > Model과 View를 연결하는 역할
- 사용자가 View에서 어떤 동작(클릭, 텍스트 입력 등)시 이벤트를 처리하여 Model을 변경 or View를 업데이트
- Controller는 Model에 데이터를 요청 or View를 갱신
- Controller는 Model을 직접 수정 가능 or View에 어떤 데이터를 어떻게 보여줄지에 대한 로직 처리
- Model과 View의 생명주기 관리
- ex) 사용자가 로그인 버튼을 클릭했을때 > 입력 정보를 Model에 전달하여 로그인처리
- ex) 사용자가 상품을 장바구니에 추가하면 > Model을 업데이트, View에 변경된 장바구니 내용 표시
3. MVC 패턴의 예시(Spring Framework)
- Spring Framework
: Java 플랫폼을 위한 오픈 소스 애플리케이션 프레임워크
> Spring의 WEB MVC는 @RequestParam, @RequestHeader, @PathVariable 등의 어노테이션을 기반으로 사용자의 요청 값들을 쉽게 분석, 사용자의 어떤 요청이 유효한 요청인지 쉽게 거른다.
4. MVC 패턴의 장단점
장점
- Model, View, Controller가 서로 독립적으로 작동해서 각 부분에 대한 변경이 다른 부분에 영향X > 확장성 용이
- UI(View)를 변경해야 할 때 Model이나 Controller를 건드리지 않고 View만 수정 가능 > 유지보수 용이
- Model을 여러 View에서 재사용 가능 > 재사용성
- Model은 데이터 처리 로직, View는 화면, Controller는 이벤트 처리 로직을 독립적으로 테스트 > 테스트 용이
단점
- 작은 애플리케이션에선 추가적인 구현 코드로 인해 관리 어려움 > 복잡성 증가
- 지나치게 모듈화된 시스템은 코드가 분산되어 관리하기 어려움 > 과도한 코드 분리
- 각각의 구성 요소가 독립적으로 처리되서 응답 시간이 길어질 수 있음 > 성능 문제
5. MVC 패턴을 사용해야 하는 경우
1. 애플리케이션이 복잡해지고 UI와 비즈니스 로직을 분리해야 할 때
- 대규모 웹 애플리케이션이나 엔터프라이즈 시스템은 UI 변경이 비즈니스 로직에 영향을 미치지 않도록 분리된 구조가 필요
2. 다양한 View에서 동일한 Model을 공유할 때
- 웹 애플리케이션에서는 같은 데이터를 여러 방식으로 표시할 수 있어야 함 > Model은 데이터 처리, View는 데이터를 다양한 방식으로 표현
3. 애플리케이션의 유지보수와 확장성이 중요할 때
- UI(View)를 변경해도 비즈니스 로직(Model)을 안건들임 > 유지보수 용이, 새로운 기능 추가 or View를 변경할 때도 다른 부분에 영향X
4. 클라이언트와 서버 간의 인터페이스가 복잡할 때
- 각각의 책임을 분리(Model-View-Controller) > 클라이언트가 서버에서 받은 데이터를 쉽게 처리
6. MVP 패턴(Model-View-Presenter Pattern)
- Controller >> Presenter
- MVC 패턴과 유사
- View와 Model 사이의 상호작용을 Presenter가 대신 처리
7. MVVM 패턴(Model-View-ViewModel Pattern)
- Controller >> ViewModel
- 데이터 바인딩과 two-way 데이터 바인딩을 지원
8. 데이터 바인딩 / two-way 데이터 바인딩
데이터 바인딩(Data Binding)
- 단방향 데이터 흐름
- Model -> View or View -> Model중 하나의 방향으로 데이터 전달
> UI에서 데이터를 수정해도 그 값은 Model에 반영되지 않으며, UI만 데이터 모델을 반영
two-way 데이터 바인딩
- 양방향 데이터 흐름
- Model <-> View 간에 양방향으로 데이터 동기화
> UI와 Model이 실시간으로 연결되어 있으며, 하나의 변화가 다른 쪽에 자동으로 반영
9. MVVM 패턴의 예시(Vue.js Framework)
*컴포넌트(Component): 재사용 가능한 UI의 조각(부분)
즉, HTML / CSS / JS로 구성된 독립적인 UI 블록
- Vue.js Framework
: 반응형이 특징인 프론트엔드 프레임워크
> watch와 computed 등으로 쉽게 반응형적인 값들을 구축할 수 있으며, 함수를 사용하지 않고 값 대입만으로도 변수가 변경되며 양방향 바인딩, HTML을 토대로 *컴포넌트를 구축할 수 있다.
10. MVC 패턴과 MVP 패턴, MVVM 패턴의 차이점
> 결국 UI와 비즈니스 로직을 어떻게 분리할것인지에 대한 차이임
| 패턴 | 중간자 | View 역할 | 데이터 흐름 | 결합도 | 특징 |
| MVC | Controller | UI + 일부 로직 | View > Controller > Model > View | 중간 | View가 Model 직접 접근 가능 |
| MVP | Presenter | UI | View > Presenter > Model <-> Presenter > View | 강함 | 테스트 용이, 명확한 분리 |
| MVVM | ViewModel | UI + 바인딩 | View <-> ViewModel <-> Model | 낮음 | 자동 바인딩, ViewModel은 View를 모름 |
MVC 패턴
- Controller가 Model과 View를 연결
- View는 Model의 데이터를 직접 가져오기도
- View와 Controller가 1:N 관계 > 하나의 View가 여러 Controller 이벤트를 가짐
MVP 패턴
- Presenter가 Model과 View를 연결
- View는 오로지 UI만 담당 > Presenter가 Model과의 상호작용을 처리
- 단위 테스트가 용이 > View는 인터페이스로 만들고 Presenter만 테스트 가능
- View와 Presenter가 1:1 관계 > MVC보다 더 강한 결합
MVVM 패턴
- ViewModel이 Model과 View의 중간자 역할
- View는 ViewModel과 데이터 바인딩을 통해 자동 UI 업데이트
- View는 단순히 UI만 표시, ViewModel은 UI 상태, 비즈니스 데이터를 처리
- 테스트 용이성 가장 좋음 > 결합도 낮음
- ViewModel은 View를 모름(완전 분리)
11. 결론
MVC, MVP, MVVM은 UI와 비즈니스 로직을 어떻게 분리하고 연결할지에 대한 구조적 차이를 가진 디자인 패턴이다.
MVC는 View가 Model에 직접 접근할 수 있어 결합도가 다소 높지만 구조가 단순하다.
MVP는 Presenter가 모든 로직을 담당하며, View는 UI만 담당해서 테스트에 유리하다.
MVVM은 ViewModel과의 바인딩을 통해 UI와 완전히 분리되어 유지보수성과 자동화가 뛰어나다.