좋은 아키텍처의 기준

Balanced Distribution - 객체의 역할이 확실하며 독립적인가? 역할 분배가 균형잡혀 있는가?

역할은 기본적으로 아래 세가지로 분류된다.
- Model - 프로그램 데이터의 조작과 관련된
- View - UI에 관한, 시각적인 요소들
- 중재자 - Controller, Presenter, ViewModel 등 (Model - View) 중간 다리 모두

Testability - 테스트 진행 가능?

Easy of Use - 사용하기 쉬운가?

Unidirectional Data Flow - 데이터 흐름이 단방향인가?

자주 등장하는 패턴들

MVC

Model - 앱의 데이터 관리

View - 유저 인터페이스 표현, 관리

Controller - Model과 View 사이 다리 역할

View의 입력을 Model이 반영
Model의 변화를 View에 갱신

View와 Controller의 강한 연결성이 가장 큰 문제 → 오로지 Model만 테스트를 진행할 수 있으며, Controller가 View의 역할까지 일부 떠안고 있다고 할 수 있음 그러나 구현이 간단하다.

MVP

다이어그램

Model - 데이터 관련

View - 시각적인 요소들. VC도 여기에 포함됨

View Controller가 Presenter를 가지고 있다 → 1:1 의존성에서는 벗어날 수 없음

Presenter - Model로부터 갱신된 데이터를 받아와서 View를 업데이트하는 역할

Life Cycle에 영향을 받지 않는다
Model 호출 여기서
Binding을 통한 것이 아닌 수동 업데이트

참조에 의한 의존성은 존재하지만, MVC 보다는 역할이 적절하게 나뉘어 있음 → 단, Presenter를 구현하기 위한 추가 코드 필요 & 구현이 조금 더 어려워진다.

MVVM

Model - 앱의 데이터 관리

View - 유저 인터페이스 표현, 관리 (ViewController도 여기에 포함)

ViewModel - 중간 역할. Ready-To-Display 상태로 값을 가지고 있다.

View와 ViewModel 사이 Binding이 존재한다.
ViewModel은 Model에 변화를 주며, ViewModel을 업데이트 한다.
이 때, 바인딩으로 인해 View도 업데이트 된다.
ViewModel은 View에 대해 아무것도 모르기 때문에 테스트가 쉽다.

역할 분리 뛰어남. 그러니 테스트도 수월. 사용성도 나쁘지 않음. Binding하기 때문에 코드가 많이 줄어들 것이다. ViewModel의 코드가 방대해질 수는 있음. → Builder나 Router를 도입하여 해결하기도 함

VIPER

"Lego building experience transferred into the iOS app design"

그 레고 블럭들을 얼마나 작게 만들 것인지는 당신의 손에 달려 있다.

Use Case 기반의 앱 디자인 → 복잡한 앱을 어떻게 작은 Use Case 단위로 나눌 것인가?

View - Presenter의 요청에 따라 데이터 디스플레이, 사용자 입력을 Presenter에 전달 (VC 여기)

Interactor - Entity를 조작. 비즈니스 로직 포함

오로지 데이터 작업만. View와 무관
Behavior나 Use Case에 따라서 Entity를 조작하는 로직이 담겨있다
- 일부 Service나 Managers들은 VIPER 바깥에서 사용하는 것으로 이해되기도 한다.

Presenter - Interactor에서 데이터를 가져오고, View에 보여줄 타이밍 결정

Entity - 모델 객체. 속성만 있는 Dumb Model

Router - 화면 전환 담당. WireFrame이라고도 함

Presenter는 언제 화면을 전환할 지 알고 있으며
Router는 어떻게 전환할 지 알고 있음 → 애니메이션 구현, ViewController 생성 등 담당
VIPER modules 사이의 연결 담당
- 모듈 사이 전환 역할에 대해서는 보통 MV(X) 패턴에서 다루지 않는다.

역할 분리라면 이 패턴을 따라갈 수 없다. 하지만 사용성 측면에서... 엄청난 양의 인터페이스를 작성해야 하기 때문에 고려가 필요함.

VIP (a.k.a. Clean Architecture)

VIPER와 객체 역할 분리 동일하나, 플로우를 다른 관점에서 본다.

VIPER는 순환 참조에 의한 메모리 누수가 날 수 있음.
VIP는 단방향 로직 순환이 특징: VC → 인터랙터 → 프레젠터 → VC

Scene을 기준으로 구조가 생성되어 있는 것이 특징

Controller를 위해 일해줄 여러 컴포넌트들, 이들 사이의 소통은 Protocol을 통한다.

Model - Entitiy의 역할을 하는. 단순 데이터 객체들

Router - Controller 사이의 화면 전환과 데이터 전달 담당

VIPER에서는 segue를 사용할 수 없지만 여기서는 가능하다.
아래의 인터페이스를 각각 구현, 채택하게 된다
- Routing Logic Protocol - 메소드로 구현, routing 기능 구현
- Data Passing Protocol - 프로퍼티로 구현되어 데이터 전달할 것 가지고 있음

Worker - Core Data, Networking 등 구체적인 일을 하는 Worker

Interactor - Worker와 Presenter 사이의 연결 다리.

아래의 인터페이스 각각
- Business Logic Protocol - View Controller가 사용할 인터페이스들
- Data Store Protocol - 주로 Router에게 전달하여 넘길 데이터 저장 프로퍼티
View Controller와 소통하여 Worker에게 필요한 매개변수들을 가져온다.
Validation 체크를 한 뒤 Worker에게 넘긴다.
Worker가 결과를 가져오면 Presenter에게 결과물을 넘긴다.

Presenter - 데이터가 사용자에게 표시될 모양새 결정