소프트웨어 디자인 패턴(MVC, MVP, MVVM)
디자인 패턴이란 소프웨어를 설계할 때 특정 부분에서 자주 발생하는 고질적 문제들이 또 발생했을 때 해결하기 위한 일반적인 접근 방법을 제공한다 예를 들어서 옵저버 패턴은 객체들 간의 의존관계를 느슨하게 유지하면서 상태 변화를 통보할 수 있는데 이는 한 객체의 변경사항을 다른 객체에 전파하면서 객체간 의존성을 제거할 수 있다 또한 코드의 가독성, 재사용성, 유지보수성을 높이기 위해서 사용된다
위 내용에 따르면 내가 선택하고 결정하는것 같지만 내가 생각하기에는 내가 어떤 언어를 사용하는가 또는 어떤 프레임워크를 사용하나에 따라서 결정되는것 같다 (이미 많은 사람들이 프레임워크, 언어를 사용한 자료들이 많기 때문에 주로 사용하는 패턴을 사용하면 되는것 같음)
그래서 유명한 디자인 패턴 MVC, MVP, MVVM에 대해서 알아보고 swiftui를 이용할 때는 왜 주로 MVVM을 사용하는지 알아본다
1. MVC(Model-View-Controller)
구성요소
Model: 애플리케이션의 데이터와 비즈니스 로직을 관리한다
View: 사용자 인터페이스(UI)를 담당합니다. 데이터를 표시하고 사용자 입력을 받는다
Controller: Model과 View를 연결하는 역할을 합니다. 사용자의 입력을 처리하고 Model의 데이터를 업데이트하거나 View를 갱신한다
동작
- 사용자의 inout은 모두 controller로 보낸다
- controller에서 사용자의 action을 확인하고 model을 업데이트 후 view를 선택한다
- view는 업데이트된 model을 보여준다
특징
view와 model의 의존성이 매우 크다
점선으로 표시된 화살표는 1개의 model이 여러 view 1:N관계를 나타낼 수 있기 때문이다 controller와 view도 1:N의 관계이다
2. MVP(Model-View-Presenter)
MVC와 model과 view는 동일하지만 controller 대신 presenter를 이용한다
구성요소
- Model: 데이터를 관리하고 로직을 처리
- View: UI를 담당 Presenter를 통해 데이터를 업데이트 받음
- Presenter: View와 Model 사이를 중재하며 로직 처리를 담당 View와 Model 간의 의존성을 제거(View와 직접 상호작용하지 않고 인터페이스로만 연결)
동작
- view를 통해서 들어온 데이터를 presenter에 요청한다
- presenter는 model에 데이터를 요청한다
- model은 presenter에 데이터를 응답
- presenter는 view에 데이터를 응답
특징
presenter는 view와 model을 연결하는 역할을 하고 presenter과 view는 1:1 관계이다 view와 model의 의존성이 없지만 view와 presenter의 의존성이 높아진다
3. MVVM(Model-View-ViewModel)
이번에도 view와 model은 동일하지만 presenter 대신 viewmodel이 사용된다 최근에 자주 사용되는 디자인 패턴
구성요소
- model: 데이터를 관리하고 로직을 처리
- View: UI를 담당 viewmodel의 데이터를 바인딩한다
- ViewModel: Model의 데이터를 가공하여 View에 제공하며 사용자 입력을 Model로 전달한다
동작
- view를 통해서 들어온 데이터를 viewmodel에 요청한다
- viewmodel은 model에 데이터를 업데이트 한다
- model은 viewmodel에 데이터를 응답
- 바인딩된 데이터를 viewmodel에서 변경되면서 view가 업데이트 된다
특징
view와 viewmodel간의 의존성이 낮아 테스트가 용이하다 데이터 바인딩을 이용해서 구현한다
SwiftUI에서 MVVM
swiftui를 통해서 개발을 진행할 때 자연스럽게 데이터 바인딩(@State, @Binding, @Published)을 사용하는데 이는 MVVM에서 view와 viewmodel을 자연스럽게 연결한다 이렇게 바인딩을 이용하기 때문에 MVVM을 사용하는것이 자연스럽다고 생각한다