iOS 아키텍처 패턴 - VIPER

iOS 아키텍처 패턴 - VIPER

원문 출처 : https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52

 

VIPER (View, Interactor, Presenter, Entity, Router)

마지막 주자 VIPER는 MV(X) 카테고리가 아니라는 점이 흥미롭다.

이제는 책임 분배가 얼마나 중요한 지에 동의할 것이다. 레고 빌딩 경험이 iOS 앱 디자인에 반영되었다.

VIPER는 기존의 MV(X) 패턴들과 다르게 3가지 카테고리가 아니라, 2가지 더 추가되어 총 5가지 카테고리를 가진다.

 

* Interactor : data(Entities) 또는 networking과 관련된 business logic을 포함한다.

(Entities의 새로운 instance를 만든다던지, 서버로부터 이들을 fetching 한다던지 등)

이러한 목적을 위해 우리는 VIPER 모듈의 일부로 간주되지 않고 외부 의존성을 띄는 Services와 Managers를 사용할 것이다.

* Presenter : UI 관련 (UIKit와는 독립적인) business logic을 포함하며, Interactor에서 메소드를 호출한다.

* Entities : 일반 데이터 객체들을 말한다. (data access layer는 포함 안됨. 이건 Interactor의 역할임.)

* Router : VIPER 모듈간의 전환(segues)을 담당한다. 

* View는 익숙할테니 생략한다.

 

기본적으로 VIPER는 application의 한 screen에만 적용 될 수도, user story 전체에 적용 될 수도 있다.

인증과정을 떠올려 보면, 하나의 스크린이 될 수도, 관련된 여러 스크린이 될 수도 있잖아?

얼마나 작은 ‘LEGO’ 블럭을 지원할 지는 전적으로 너에게 달렸어!

---

MV(X) 패턴과의 차이

* 데이터 상호작용 로직을 담당했던 Model의 기능은 / VIPER에선 Interactor와 dumb한 data structure인 Entities로 나뉘어 이전됐다.

(Entities는 단순히 데이터 객체들을 담을 뿐 상호작용이라던지 이런 기능이 없으므로 dumb하다고 표현)

 

* Controller/Presenter/ViewModel의 오직 UI 표시 의무만 VIPER의 Presenter로 이동하였고, 데이터 변환 기능은 이동하지 않았다. (VIPER의 Present에는 data altering capabilities가 없다.)

 

* VIPER는 Router에 의해 풀리도록 되어있는 주소 네비게이션 책임을 명시적으로 다루는 첫번째 패턴이다.

 

VIPER에서는 iOS application에 적용할 적절한 라우팅 방식을 고르는 문제가 있다. MV(X) 패턴에서는 이런 이슈를 다루지 않는다.

---

좋은 아키텍처의 3가지 특징

 

- Distribution : 의심할 것도 없이 VIPER는 책임 분배의 챔피언이다!

 

- Testability : 놀랄 것도 없이, 책임 분배의 명확성(독립성)은 더 좋은 testability를 만든다.

 

- Easy of use : 예상했겠지만 위 두 요소에는 많은 유지보수 비용이 따라온다. 매우 작은 책임을 가지는 클래스들을 위한 엄청나게 많은 인터페이스를 작성해야 한다.

---

VIPER 문제점

VIPER를 사용하는 동안에 레고로 엄~~~청나게 큰 건물을 짓는다는 느낌을 받았을 것이다. 이건 뭔가 문제가 있다는 신호이기도 하다.

아마도 당신의 어플리케이션에 VIPER를 적용시키는 것은 너무나도 이르다. 좀 더 단순한 패턴을 고려하는 게 좋을 거다.

몇몇 사람들은 이를 무시하고 참새에게 기관포를 쏘는 행위를 계속 하는데, 지금 당장은 유지보수 비용이 엄청나게 들더라도, 적어도 미래의 언젠가는 VIPER 패턴으로 이득을 볼 것이라고 생각하기 때문이겠지?

이렇게 생각하는 게 맞다면 VIPER 골격을 만들어주는 툴인 ’Generamba’를 써보기를 추천한다.

---

결론

여러가지 아키텍처 패턴을 살펴봤다. 너를 괴롭혔던 것에 대한 답을 얻었기를 바라지만, 아키텍처 패턴을 선택하는 문제는 완벽한 정답이란 없고, 특정 상황에 맞는 패턴을 저울질 하는 문제라는 것을 깨달았을 거라 생각한다.

 

그러므로 같은 하나의 앱 안에서 여러가지 아키텍처를 섞어 사용하는 것은 자연스러운 현상이다. 예를 들어 MVC 패턴으로 시작했더라도 특정 screen은 MVC로는 효율적으로 관리하기 힘드므로 이 부분에 대해서는 MVVM 방식을 택한다던지, 이 두 아키텍처는 쉽게 호환이 가능하므로 MVC로 잘 돌아가고 있는 다른 screen까지 MVVM으로 바꿀 필요는 없다. (특정 screen에만 특정 패턴 적용 가능)