-
[디자인 패턴] MVC 패턴? MVP 패턴? MVVM 패턴?디자인 패턴 2024. 6. 1. 13:40
MVC (Model - View - Controller) 패턴
- Model, View, Controller 세개의 컴포넌트로 구성되어 있는 패턴이다
1. Model
- 애플리케이션의 데이터인 데이터베이스, 상수, 변수 등을 뜻한다
- 애플리케이션의 데이터 및 비즈니스 로직을 담당
- 뎅이터베이스와의 상호작용, 데이터 검증 등을 수행한다
2. View
- 사용자 인터페이스 요소를 나타낸다
- 모델을 기반으로 사용자가 볼 수 있는 화면을 뜻한다
- 사용자 입력을 컨트롤러에 전달한다
- 모델이 가지고 있는 정보를 따로 저장하지 않아야 한다
3. Controller
- 모델과 뷰를 잇는 다리 역할을 한다
- 모델과 뷰의 생명주기를 관리한다
- 사용자 입력을 처리하고 모델을 업데이트하며 모델에서 받은 데이터를 뷰에 전달한다
장점
- 재사용성과 확장성이 용이하다
단점
- 애플리케이션이 복잡해질수록 모델과 뷰의 관계가 복잡해지는 단점이 있다
MVP (Model - View - Presenter) 패턴
- MVP 패턴은 MVC 패턴에서 발전된 형태로, 컨트롤러 대신 프레젠터를 사용합니다.
1. Model
- MVC 패턴과 동일하다
2. View
- 모델과 직접적으로 상호작용하지 않으며 프레젠터를 통해 모델과 상호작용한다
- 사용자 인터페이스를 담당한다
- View는 데이터를 표시하고, 사용자 입력을 Presenter에 전달한다
3. Presenter
- 뷰와 모델 사이의 중재자 역할을 한다
- 사용자의 요청을 처리하고 모델을 업데이트하고 모델의 상태를 뷰에 반영한다
동작 과정
- View가 사용자 입력을 받는다.
- View가 Presenter에게 데이터를 요청한다.
- Presenter는 Model에게 데이터를 요청한다.
- Model은 Presenter에게 데이터를 리턴한다.
- Presenter는 View에게 데이터를 전달하고 UI를 갱신한다.
장점
- 테스트 용이성 증가 -> 프레젠터를 독립적으로 테스트 가능하다
단점
- 뷰와 프레젠터 간의 상호작용이 복잡할 수 있다
MVC 패턴과 차이점
1. 컨트롤러 vs 프레젠터
- MVC에서는 컨트롤러가 사용자 입력을 처리하고 모델을 업데이트하는 주된 역할을 한다, 컨트롤러는 뷰와 모델 사이의 상호작용을 관리한다
- MVP에서는 프레젠터가 뷰와 모델 사이의 모든 상호작용을 관리한다, 프레젠터는 뷰와 모델을 완전히 분리시키며, 뷰는 프레젠터를 통해서만 모델과 상호작용한다
2. 뷰와 모델 간의 직접 상호작용
- MVC에서는 뷰가 모델을 직접 참조하여 데이터를 가져올 수 있다
- MVP에서는 뷰와 모델이 직접적으로 상호작용하지 않는다, 모든 데이터 교환은 프레젠터를 통해 이루어진다
3. 테스트 용이성
- MVP는 뷰와 프레젠터가 분리되어 있기 때문에 단위 테스트가 더 용이합니다. 프레젠터를 독립적으로 테스트할 수 있습니다.
- MVC에서는 컨트롤러가 뷰와 모델과 더 밀접하게 결합되어 있어 테스트가 다소 복잡할 수 있습니다.
MVVM (Model - View - ViewModel) 패턴
- 사용자 인터페이스(UI)와 비즈니스 로직을 더 잘 분리하기 위해 고안된 소프트웨어 아키텍처 패턴이다
1. Model
- 데이터와 비즈니스 로직을 담당한다
- 데이터베이스와의 상호작용, 비즈니스 규칙, 데이터 검증 등을 처리한다
- 보통 데이터베이스, 네트워크 요청 또는 파일 시스템과 같은 데이터 소스와 상호 작용한다
- 순수한 데이터 구조와 로직으로, UI에 대한 정보가 전혀 없습니다.
2. View
- 사용자 인터페이스를 담당하는 부분이다
- 사용자가 보는 화면을 표시하고, 사용자 입력을 처리한다
- 보통 XAML, XML, HTML 등과 같은 마크업 언어를 사용하여 디자인된다
3. ViewModel
- View와 Model 사이에서 중재자 역할을 수행한다
- View에서 발생하는 이벤트를 감지하고, 해당 이벤트에 맞는 비즈니스 로직을 수행한다
- View와 데이터 바인딩을 통해 직접적으로 상호작용한다
- Model과 상호작용하여 데이터를 가져오거나 업데이트하고, View에 데이터를 업데이트하는 역할을 한다
동작 과정
1. 사용자의 요청을 View를 통해 들어온다
2. 해당 요청을 ViewModel에 전달한다
3. ViewModel은 Model에게 데이터를 요청한다
4. Model은 요청받은 데이터를 응답한다
5. ViewModel은 응답 받은 데이터를 가공하여 저장한다
6. 데이터 바인딩을 통해 View는 ViewModel의 데이터를 자동으로 반영하며,
ViewModel의 변경 사항이 자동으로 View에 업데이트된다
장점
- UI와 비즈니스 로직이 분리되어 코드의 유지보수성과 재사용성이 높아짐
- UI가 개발되지 않아도 개발이 가능하다
- ViewModel과 Model이 독립적으로 테스트 가능하여 유닛 테스트가 용이하다
- 데이터 바인딩을 통해 View는 상태 변화를 자동으로 반영하기 때문에 코드의 복잡도가 줄어든다
- 뷰와 뷰모델이 1:n 관계이기 때문에 중복되는 로직을 모듈화 해서 여러 뷰에 적용할 수 있다 (코드 재사용 가능)
단점
- 데이터 바인등과 같은 개념을 알아야한다
- 단순한 애플리케이션에서는 MVVM 패턴을 적용하는 것이 오히려 복잡성을 증가시킬 수 있다
- 데이터 바인딩으로 인한 메모리 소모가 심하다
- 설계가 복잡하다