[iOS Architecture] VIPER

안녕하세요 이누입니다.

 

오늘은 많이 들어만보고 뭔지는 아직도 모르는 VIPER 패턴에 대해 학습해봤습니다.

---

VIPER 패턴?

먼저 VIPER 패턴입니다. VIPER는 View, Interactor, Presenter, Entity, Router의 약자입니다.

이름대로 이 5개의 요소로 UI 구성 패턴을 정의합니다.

https://www.youtube.com/watch?v=hFLdbWEE3_Y

각 요소들은 위와 같이 상호작용하며 자신의 역할을 수행합니다. 각 요소의 역할은 다음과 같습니다.

View

• ViewController를 포함해 화면에 보여지는 모든 것들이 여기에 포함됩니다.
• Presenter에 대한 참조를 보유합니다.
• Presenter에서 호출하여 자신을 변경할 수 있는 메서드를 내부에 보유합니다. (다른 방식으로 Presenter의 이벤트를 확인해 직접적으로 처리하도록 할 수도 있습니다.)

Interactor

• 앱의 비즈니스로직을 담고 있습니다.
• 주로 API 호출 등의 데이터관련 로직이 포함됩니다.
• Presenter에 대한 참조를 보유합니다.
• Presenter에서 호출하여 비즈니스 로직을 실행할 수 있는 메서드를 내부에 보유합니다. (다른 방식으로 Presenter의 이벤트를 확인해 직접적으로 처리하도록 할 수도 있습니다.)
• 비즈니스 로직이 종료되고 필요할 경우 Presenter에 데이터를 전달합니다.

Presenter

• View 및 Interactor를 기반으로 데이터를 불러오고 화면에 적용하는 역할을 수행합니다.
• View 및 Interactor, Router에 대한 참조를 보유합니다.
• View로부터 액션을 받아 Router에 화면전환을 요청합니다. (Router의 메서드 이용 혹은 이벤트 발생)
• View로부터 액션을 받아 Interactor에 데이터를 요청합니다. (Interactor의 메서드 이용 혹은 이벤트 발생)
• Interactor로부터 받은 데이터 모델을 기반으로 View를 변경합니다. (View의 메서드 이용 혹은 이벤트 발생)

Entity

• 단순한 데이터 모델입니다.
• 일반적으로 API를 기반으로 불러오는 데이터가 해당됩니다.

Router

• 언제 어떤 화면을 띄울지에 대한 Navigation 로직을 가지고 있습니다.
• 주로 내부 static 메서드인 start()를 통해 생성합니다. (물론 가장 일반적인 네이밍일뿐, 이는 변경될 수 있습니다.)
• start 과정에서 View, Interactor, Presenter를 생성하고 할당합니다. 이 때, 각 요소에서 필요로 하는 다른 요소도 할당해줍니다.
• 화면 전환을 수행할 수 있는 메서드를 내부에 보유합니다. 
• View를 일종의 Entry Point로 보고 전환을 수행합니다.

초기화면이 될 UI의 Router는 SceneDelegate에서 Router의 static 메서드인 start()를 통해 생성됩니다.
그리고 Router 내부에 존재하는 View를 initialViewController로 활용해 첫 화면을 실행합니다.

이렇게되면 View에서 Presenter를 가지고 있고 Presenter에서 다른 View 및 Interactor, Router에 대한 참조를 보유하기 때문에 모든 인스턴스가 메모리에 올라가게 되겠죠? 이렇게 작업이 수행되는 것입니다.

VIPER 장단점

장점

• 확실히 기존의 MVC 패턴의 Massive View Controller 문제를 어느정도 해결했습니다.
• 각 요소를 protocol을 통해 의존성만 잘 나눠준다면, Testability도 좋을 것으로 보입니다.
• Router의 존재로 기존의 MVX 패턴(MVP, MVVM)보다 확실한 책임분리를 이뤄냈습니다.

단점

• 일단 Presenter와 View, Presenter와 Interactor가 서로를 보유하고 있다는 점부터 불편합니다. 이렇게될 경우 순환참조가 발생할 수 있습니다. weak로 순환 참조 문제를 해결하더라도 단방향 통신을 하지 않고 양방향 통신을 수행한다는 특징이 여전히 존재합니다. 
• 코드 생성량이 많아 처리가 부담스럽습니다.
• 명확한 가이드나 템플릿이 부족해 정확한 설계가 어렵습니다. 

---

VIPER는 명확한 가이드가 없어 학습도 어렵네요. 그래도 핵심은 View, Interactor, Presenter, Entity, Router로 역할을 나눌 수 있다는 점인 것 같습니다. 이외에 데이터전달 방법이나 생성방법 등은 다른 아키텍처가 그렇듯 바뀔 수 있겠죠?

 

좀 더 공부해서 새롭게 느끼는바가 있다면 수정 및 추가하겠습니다!

잘못된 부분이 있다면 댓글 부탁드려요.