[Design Pattern] MVC, MVP, and MVVM

MVC(Model-View-Controller)

Model, View, Controller의 세 가지 요소로 이루어지는 디자인 패턴.

• Model : 비즈니스 로직과 데이터 모델이 정의되어 있음
• View : 사용자에게 주어지는 UI
• Controller : View와 Model 사이의 중재자 역할

View가 Model을 직접 참조하지 않고, Controller를 통해 간접적으로 접근하여 필요한 데이터를 얻어낸다.
즉 직접적인 의존성을 제거하는 패턴.

작동 방식

1. User가 View를 통해 액션
2. Controller는 이 액션을 받아서 Model에 접근하여 처리
3. Model의 변경이 View에 반영

장단점

• 장점 : 관심사의 분리와 이를 통한 유지보수성/독립성
• 단점 : Controller가 비대해질 가능성이 존재하며, View와 Model이 완전히 독립되지는 않음

MVP(Model-View-Presenter)

Model, Presenter, View의 세 가지 요소로 이루어지는 디자인 패턴.

• Model : MVC의 모델과 마찬가지로, 비즈니스 로직과 데이터 모델이 정의되어 있음
• View : 사용자에게 주어지는 UI로, 유저의 입력을 받는 역할
• Presenter : View와 Model 사이의 중재자 역할. 하나의 View와 일대일 대응됨.

MVC에서는 Model의 변경사항이 Event를 통해 View로 전달되었지만, MVP에서는 Presenter가 모든 View-Model간 상호작용을 중개하게 된다.

작동 방식

1. View가 사용자 입력을 받음
2. View는 Presenter에 작업을 요청
3. Presenter가 Model을 통해 데이터를 처리
4. Model이 Presenter에 결과를 반환
5. Presenter가 View를 업데이트

장단점

• 장점 : Model과 View가 완전히 분리되어 유닛 테스트가 용이하다. UI 로직과 비즈니스 로직이 명확히 분리된다.
• 단점 : View마다 Presenter가 존재하고, Presenter가 많은 책임을 가지므로 서비스가 복잡해질 수 있다.

MVVM(Model-View-ViewModel)

• Model : MVC의 모델과 마찬가지로, 비즈니스 로직과 데이터 모델이 정의되어 있음
• View : 사용자에게 주어지는 UI로, 유저의 입력을 받는 역할
• ViewModel : View와 Model 사이의 중재자 역할. View와 ViewModel은 Many To One으로 대응됨.

MVP와는 다르게, View와 ViewModel은 Many To One으로 연결된다. 따라서, View는 ViewModel을 참조하지만, ViewModel은 하나의 View를 참조하지 않는다. 대신에 Observer Pattern을 통해 변경 사항을 View에 전달하게 된다.

작동 방식

1. View는 사용자 입력을 받아 ViewModel에 전달
2. ViewModel은 필요한 경우 Model을 업데이트
3. Model이 변경되면 ViewModel을 업데이트
4. View는 데이터 바인딩을 통해 자동으로 업데이트

장단점

• 장점 : 데이터 바인딩을 통한 자동 동기화, ViewModel의 높은 재사용성
• 단점 : 데이터 바인딩에 의한 디버깅 어려움, 대형 서비스의 경우 ViewModel이 복잡해짐.