MVC
좌: 오리지널 MVC, 우: Apple MVC
장점
- 설계가 단순하기 때문에 가장 쉽고 빠르게 개발이 가능하다.
- 애플에서 MVC를 지향하고 있기 때문에 기본 Life Cycle에 맞는 개발이 가능하다.
단점
- View와 Model이 서로 의존적이다.
- Controller의 역할이 방대해져서 모듈화하는 부분이 무의미해질 수 있다.
- 위의 이유로 대규모 프로젝트에는 비적합하다.
- View가 독립적이지 않기 때문에 테스트 용이성이 떨어진다.
MVP
Presenter의 역할: UIKit 독립적인 중재자
Presenter는 View를 갱신하기 위해, View의 요소에 직접 관여합니다. 이러한 이유로 View를 소유하기 때문에 높은 의존성을 가지게 된다. 높은 의존성을 가지면 어떻게 될까? 테스터블하지 못하고, 재사용성이 떨어진다.
MVVM
ViewModel의 역할: UIKit 독립적인, 뷰 표현에 대한 책임을 가진 객체
장점
의존성이 깨지기 때문에 테스트 용이성 향상, 재사용성 향상, 가독성 향상
단점
- ViewModel 이 Model 과 View 의 사이에서 양방향으로 통신하기 때문에 앱이 복잡해질 수록, Controller가 그랬듯이 ViewModel이 무거워진다.
- 데이터 바인딩이 요구되는 등, ViewModel은 설계가 어렵다.
- 표준화된 틀이 없기 때문에 이용자 별로 다른 방식으로 정의한다.
MVI
MVVM에서 ViewModel이 무거워지는 문제를 해결하기 위해서, 뒤를 돌아보지 않는 단방향의 아키텍쳐인 MVI가 고안되었다. View에서 액션을 입력 받으면 Intent 에서 모델의 상태를 변환시키고, 그 변환된 상태의 모델을 뷰에 전달하여 유저에게 보여준다.
VIPER
VIPER는 책임 분리의 원칙(SRP)을 기반으로 한다.
- 책임 분리의 원칙(SRP): 작성된 객체는 하나의 기능만 가지며 객체가 제공하는 모든 서비스는 그 하나의 책임(기능)을 수행하는 데 집중되어 있어야 한다는 원칙. 높은 응집도와 낮은 결합도를 야기한다.
View: UI만을 담당. Presenter의 의지대로 UI를 update하기 때문에 Presenter 의존적이다.
Presenter: UIKit 독립적인 중재자. View에게 받은 이벤트를 Interactor를 통해 처리, Router를 통해 화면 전환 처리를 하여 View에게 전달한다. View, Router, Interactor 의존적이다.
Interactor: 비즈니스 로직을 담당, API 통신 등의 네트위킹이나 Entity(Data)에 대한 처리를 하고 결과를 Presenter에게 전달한다.
Router(WireFrame): 화면 전환과 각 구성 요소에 DI(의존성 주입)을 처리한다.
Entity: 속성들을 가지고 있는 Data Model을 의미한다.
장점
- Router로 인해 기존의 아키텍처보다 책임 분리가 확실하다.
- 이러한 책임 분리로 인해 Presenter와 Interactor를 유닛테스트할 수 있다.
단점
- 여전히 Presenter와 Router는 여러 객체들에 의존적이다. 그러나 이를 프로토콜로 처리한다면 어느 정도 테스터블해질 수 있다.
- 작은 기능도 모듈 단위로 개발을 해야하기 때문에 생산성이 떨어진다.
- MVVM과 마찬가지로 표준화된 틀이 없다.
VIP (Clean Swift)
- Clean Architecture를 iOS앱 개발에 적용시킨 아키텍처.
- VC → I → P → VC 로 데이터가 흐르기 때문에 단방향 플로우를 가진다.
ViewController: 화면 업데이트 담당
Interactor: 비즈니스 로직 담당
Presenter: Interactor의 비즈니스 로직을 통해 처리된 데이터를 받아 화면에 노출할 수 있도록 데이터 변경
Worker: 네트워킹이 필요한 경우, Interactor에서 처리하지 않고 Worker에서 처리하도록 분리할 수 있다. Interactor와 Worker 모두 독립성이 보장된다.
Router: 화면 전환 담당. 넘겨주어야 하는 데이터가 있다면 Router를 통해 함께 보내준다.
(VIP에 대한 추가적인 공부 후 업데이트)
결론
Swift와 함께 사용되거나 자주 거론되는 아키텍처의 개요와 장단점을 정리하면서, 새로운 아키텍처가 계속해서 발생하는 이유는 표면적으로 책임을 분리하고 낮은 결합도를 가지기 위해서라는 생각이 들었다.
좋은 구조, 잘 짜여진 코드란 무엇일까? 개발자가 개발을 하는 이유는 문제를 해결하기 위해서라고 생각된다. 회사에 소속되어있다면 그 문제는 비즈니스 문제일 것이며, 많은 개발자들이 시간을 들여서라도 좋은 구조를 만들기 위해 노력하는 것은 결과적으로 비즈니스 문제에 대한 해결 방법이라는 (자신없는) 결론을 도출시켜 보았다.
책임을 분리하고 낮은 결합도를 가지는 것이 최종적인 장점이라고 볼 수는 없지 않을까? 이러한 장점들을 야기시켜서 개발자가 얻고자 하는 바가 무엇인지에 대해서 계속 고민해봐야겠다.
지금은... 모르겠다. 모르는 게 당연함.
