개발콩블로그
[iOS] MVC, MVP, MVVM 아키텍처 패턴에 대한 느낀점 본문
안녕하세요! 개발콩입니다.
오늘은 MVC, MVP, MVVM 대한 간략한 정리와 제 생각을 정리하기 위해 게시글을 작성합니다.
MVC
Model
- 데이터와 비즈니스 로직을 담당합니다.
- UI와 완전히 독립적으로 동작합니다.
View
- 사용자에게 보여지는 UI 요소입니다.
- 사용자의 입력을 받습니다.
Controller
- Model과 View사이의 중재자 역할을 합니다.
- View로부터 사용자 입력을 받아 Model을 업데이트합니다.
- Model의 변경사항을 View에 반영합니다.
우리는 View의 속성과 입력, delegate, datasource, addtarget, 네트워크 통신을 모두 ViewController에 작성하는 경우가 많습니다.
apple의 네이밍 ViewController에서 볼 수 있듯이 View와 Controller는 밀접하게 연관되어 있습니다.
View와 Controller의 역할을 모두 수행하기 때문에 Massive View Controller 문제가 발생할 수 있습니다.
MVP
Model
- 데이터와 비즈니스 로직을 담당합니다.
- UI와 완전히 독립적으로 동작합니다.
View
- 사용자에게 보여지는 UI 요소입니다.
- 사용자의 입력을 받습니다.
- Presenter에 사용자 입력을 전달합니다.
Presenter
- Model과 View사이의 중재자 역할을 합니다.
- 비즈니스 로직을 처리하고 View를 업데이트합니다.
모든 상호작용이 Presenter를 통해 이루어집니다.
여기서 중요한 것은 View와 Presenter가 1:1로 관계로 서로 알고 있습니다.
Presenter는 weak키워드를 통해 View를 약한 참조를 통해 사용할 수 있습니다.
이 과정에서 View가 반영해야하는 것에 대한 프로토콜 정의
Presenter가 수행해야하는 것에 대해 프로토콜 정의를 활용하여
추상화를 통해 테스트 가능한 함수를 수행할 수 있습니다.
MVVM
Model
- 데이터와 비즈니스 로직을 담당합니다.
- UI와 완전히 독립적으로 동작합니다.
View
- 사용자에게 보여지는 UI 요소입니다.
- 사용자의 입력을 ViewModel에 전달합니다.
- ViewModel의 데이터를 관찰하고 UI를 업데이트합니다.
ViewModel
- View에 표시될 데이터를 가공하고 비즈니스 로직을 처리합니다.
- Model의 변경사항을 반영합니다.
ViewModel은 View에 대해 알지 못합니다.
ViewModel은 비즈니스 로직에 대한 처리만 수행하며, View는 ViewModel을 관찰하고 값이 변경될 경우 이것을 반영합니다.
View: ViewModel은 1:N이 될 수 있습니다. (예: 공통된 큰 단위의 한 화면에서 작은 단위의 View가 있을 경우 해당 View마다 ViewModel이 있을 수 있다.)
제 결론 및 느낀점
MVC에서 View와 Controller는 강하게 결합되어 있습니다.
맨 처음 MVC패턴의 코드를 작성할 때에는
View 속성, 비즈니스 로직, 유저 액션에 대한 처리, 화면 전환에 관련된 로직, 네트워크 통신 코드 등
모든 코드를 ViewController에 작성을 하며 개발을 했습니다.
이렇게 되면서 Massive한 ViewController가 되었고, 몇 달이 지난 뒤 코드를 보게된다면 코드의 흐름을 파악하기 어려웠고,
많은 책임을 하나의 ViewController가 갖게되면서 유지보수의 어려움이 있었습니다.
그러던 중, 비즈니스 로직을 따로 분리해볼까? 네트워크 통신 코드를 분리해볼까?라는 생각이 자연스럽게 생겼고
역할에 대해서 분리를 시작하고, 이러한 개발자들의 경험과 규칙들이 모여 아키텍처 패턴이 정립된 것 같습니다.
뷰의 입출력과 해당 입력에 대한 비즈니스 로직 등을 분리를 시도한 것이 MVP의 Presenter이며, MVVM의 ViewModel인 것 같습니다.
결국 모든 패턴의 시작은 책임을 어떻게 분리할까?라는 고민에서 시작되는 것 같습니다.
화면 전환에 대한 로직을 따로 관리한다면 Coordinator Pattern이 등장한 것이고
비즈니스 로직을 분리하는 것에 대해서 MVP, MVVM이 등장하게 되었으며
결국 책임을 더 잘 분리하게 된다면 클린 아키텍처와도 연결되는 것 같습니다.
하지만 여기서 중요한 것은 결국 아키텍처에는 절대적으로 누가 좋고, 누가 나쁘고가 없다는 것 입니다.
특정 상황에서는 MVC가 옳을 수도, 특정 상황에서는 MVVM이 옳을 수도 있다는 점 입니다.
아키텍처에 종속된 코드를 작성하는 것이 아닌, 상황에 맞는 아키텍처를 적용하는 것이 중요하다는 것을 다시 한번 느끼며
아키텍처는 결국 역할을 어떻게 분리할 것인지 정의한 것이다라는 느낌을 남기며 글을 마칩니다.
'iOS' 카테고리의 다른 글
| [iOS] UILabel에서 특정 텍스트 변경하기 (NSMutableAttributedString) (0) | 2025.02.16 |
|---|---|
| [iOS] Image Resize & DownSampling을 통한 최적화 (0) | 2025.01.21 |
| [iOS] UICollectionView 동적 크기 Cell 만들기 (1) | 2025.01.18 |
| [iOS] Hugging Priority, Compression Resistance Priority (0) | 2025.01.13 |
| [iOS] 키보드에 따른 Layout 설정하기 - Keyboard Layout Guide (0) | 2025.01.11 |
