6월 4일에 열린 컴공선배의 iOS 컨퍼런스에 참가했습니다. 큰 주제는 디자인 패턴이었습니다. 저는 지금까지 MVC와 MVVM 패턴을 사용해보았고 특히 MVVM 패턴으로만 프로젝트를 진행 해왔었습니다. 지금 회사에서 참가하고 있는 프로젝트도 모두 MVC (오래된 프로젝트) 아니면 MVVM으로 진행하고 있고 있었기에 다양한 디자인 패턴을 접해볼 수 있는 좋은 기회였습니다.

MVVM

MVC

UIKit은 UIViewController라는 클래스가 있기 때문에 MVC 패턴을 사용하는 것이 자연스러운 일이었습니다. 하지만 앱이 복잡해질 수록 Controller가 커지게 되고 view와 비지니스 로직을 구분해서 test하기도 어려워지는 단점이 있습니다..

MVVM

(다이어그램 출처: https://ko.wikipedia.org/wiki/모델-뷰-뷰모델)

Controller가 View와 Model을 전부 관리하는 MVC와는 다르게 MVVM의 VM은 데이터를 처리하는데 집중하고 View가 화면을 보여주는데 집중합니다.

View와 VM은 데이터 바인딩을 통해 연결합니다. ViewModel에서 데이터가 변경되면 View에 반영되도록 하는 것이 데이터 바인딩입니다. 데이터 바인딩을 구현하기 위해서는 RxSwift를 사용합니다.

MVVM 단점

표준이 없다! : 표준화된 MVVM의 템플릿도 없고 테스트 코드의 표준 또한 없습니다.

RIBs

(RIBs 이미지 출처: https://github.com/uber/RIBs/wiki)

우버에서 개발한 아키텍쳐로 안드로이드와 동일한 아키텍쳐를 사용할 수 있기 때문에 Cross-platform으로 소개됩니다.

구조

Router, Interactor, Builder가 하나의 RIB을 구성합니다. 각각 Router는 RIB 간의 이동, Interactor의 비지니스 로직, Builder는 RIB을 인스턴스화하는 것을 담당합니다.

Router

RIB들은 Hierarchy를 이루고 있다. 부모 RIB은 자식 RIB에 데이터를 전달합니다. Router는 Interactor에게 정보를 받아서 자식 RIB을 attach하고 dettach하는 역할을 합니다. (자식 RIB only❗️)

Interactor

비지니스 로직을 담당하는 객체입니다. Testable하고 Isolated하게 짜는 것이 중요합니다.

Builder

RIB들의 인스턴스화를 담당합니다. RIB에서 Dependency Injection에 대한 정보를 담고 있는 유일한 클래스이기도 합니다. (따라서 Builder만 교체하면 다른 Dependency를 사용해서 RIB을 재활용할 수 있습니다.)

View

UI를 만들고 업데이트하면 사용자의 interaction을 다루는 객체입니다. 최대한 dumb하게 짜서 화면을 보여주는 기능만 하도록 만들어야 합니다. (RIB이 존재하더라도 View는 없을 수도 있으므로 optional입니다. ex. root RIB의 경우)

Component

Builer를 도와서 Dependency Injection을 담당합니다.

RIBs의 장단점

장점

Protocol Oriented Programming

서로 의존성이 적다 (Low Dependency) = Unit 테스트를 잘 만들기 쉽다.

단점

러닝 커브가 높다

Rx에 의존적이다.

Boilerplate: 작은 기능을 구현할 뿐인데도 코드양이 많다.

ReactorKit

(ReactorKit 이미지 출처: https://github.com/ReactorKit/ReactorKit)

flux와 reactive programming의 조합으로 View의 State와 User의 Action이 observable의 stream을 통해서 전달됩니다. 데이터는 Reactor에서 발행한 State가 View에 반영되고 View에서 받은 Action이 Reactor로 흘러가는 단방향 흐름입니다.

각각의 역할

View

UI를 담당하는 부분입니다. 사용자의 입력을 action stream과 바인딩하고 State를 UI와 바인딩합니다. 각각의 View 하나마다 Reactor를 하나씩 가지고 있습니다.

Reactor

MVVM의 ViewModel과 유사한 역할을 하고 있습니다. 비즈니스 로직을 담당합니다. 내부에 Action, Mutation, State를 정의합니다. (Action과 Mutation은 enum, State는 struct)

Action은 유저의 상호작용, State는 View의 상태를 의미하면 Mutation은 Action과 State를 연결하는 중간 다리 역할을 합니다.

Reactor 내부의 mutate 함수는 Action을 입력 받아서 Observable을 리턴하고 reduce 함수는 기존의 State와 Mutation을 입력 받아서 새로운 State를 리턴합니다.

ReactorKit의 장점

Testability

비지니스 로직을 뷰로 부터 분리합니다. 리액터는 뷰에 의존성을 가지지 않습니다.

Start Small

어플리케이션 전체에 아키텍쳐의 사용을 강제하지 않습니다. 부분적으로 적용이 가능합니다.

Less Typing

다른 아키텍쳐에 비해서 적은 코드를 사용합니다.