-
VIPER 뿌셔보기 (1)VIPER 2023. 8. 2. 23:05
안녕하세요. 그린입니다 🍏
이번 포스팅에서는 오랜만에 시리즈로 써볼까해요!
주제는 VIPER입니다 😃
아키텍쳐들 조금씩 봐야지 봐야지~ 하다가 한번에 다 공부하고 정리하기는 당연히 벅찰것 같아서 조금씩 나눠서 시리즈로 배워볼까했어요.
그래서 평소 관심이 있던 VIPER 아키텍쳐에 대해 찍먹 느낌으로 하다가 딥 다이브해보는 그런 시리즈를 만들어보려고 계획중이자 스스로 약속하고 있습니다!
계획 잘 지킬 수 있도록 진짜 쪼오금씩 꾸준히 해보자 미래의 나야...
그럼 VIPER 시작해볼께요 🕺🏻
우선 VIPER 아키텍쳐가 뭔지부터 알고 가야하기에 이번 포스팅에서는 VIPER 도대체 뭔지 찍먹 갑니다!
VIPER 넌 대체 뭐야?
우선 VIPER를 검색하면 많은 글들에서 나오는 대표적인 흐름 구조도가 있어서 저도 가져와봤어요!
일단 요런 구조를 띄고 있습니다.
그럼 여기서 유추할 수 있는게 있어요.
VIPER의 약자는 보이는 각 역할들인 View, Interactor, Presenter, Entity, Router의 앞글자를 딴것이죠.
그래서 우리가 가장 먼저 살펴봐야하는 부분이 저 각 역할들을 나눈 기준들과 어떤 역할을 하는지입니다!
View
SwiftUI에서는 View 자체를 의미할것 같고 UIKit에서는 ViewController를 의미하는 이 View는 오로지 UI에 대해서만 신경씁니다.
즉 UI를 그리기 위해 어떻게 그려줄것인지 어떤 구성요소로 그려줄것인지만 관심을 가지고 그 역할에 충실합니다.
보시면 Presenter를 소유하고 있고 유저의 UI에서 발생한 액션들을 Presenter로 보내줍니다.
예를들어, 유저의 버튼 터치 및 스크롤, 드래그 등 모든 인터랙션이 발생하는것을 Presenter에 보내주는것이죠.
즉, Presenter는 이러한 인터랙션의 처리를 View로부터 전달 받고 UI를 업데이트하여 View를 갱신합니다.
여기서 View는 직접 인터랙션 처리를 하는것이 아닌 가장 핵심은 정말 UI를 그려주고 보여주는것 외에 자신이 하는것이 없습니다.
Interactor
Presenter에서 대게 호출되며 비지니스 로직에 관한 부분들을 처리합니다.
Interactor는 데이터와 유스케이스로 구성이 되어 있어요.
여기서 데이터는 데이터 자체를 의미할테고 유스케이스는 비지니스 로직을 수행할 다양한 로직 케이스를 의미합니다.
실제로 네트워킹 및 시스템 단의 서비스 등을 요청해야 한다면 이 Interactor가 제 역할을 해줍니다.
또한, Interactor는 Entity를 알고 있습니다.
예를들어 통신을 통해 데이터를 갱신받아 뷰를 업데이트 해줘야 한다면 Presenter가 Interactor에 요청하고 Interactor에서 실제 API 호출 등 통신이 이뤄지고 이 통신으로 가져온 response를 통해 Entity를 처리해서 Presenter에 뷰 업데이트를 위해 전달하는 역할을 해주죠.
핵심은 Interactor는 비지니스 로직을 처리하는 친구다! 라고 알면 될것 같네요.
Presenter
가장 많이 엮여 있는 Presenter는 우선 View, Interactor, Router와 의존 관계입니다.
즉, View에서 인터랙션이 들어오면 Interactor의 해당하는 유스케이스를 거쳐 처리하게 되고 처리된 결과를 Interactor에서 알려주면 다시 View에 업데이트된 데이터를 보내 UI를 업데이트 시켜줄 수 있습니다.
또한, Router를 거쳐 뷰 전환 등의 역할을 수행하죠.
Entity
실제 뷰를 그려주기 위해 데이터가 필요하다면 이 데이터 모델이 있을것이고 그것이 바로 Entity입니다.
Interactor의 비지니스 로직을 통해 처리될때 이 Entity가 변경되고 실제 뷰 데이터에 영향을 주는 부분이죠.
Router
보통 실제 코드 예시들에서 살펴볼때는 WireFrame이라고 많이 표기되고 사용되는것 같은데요.
이 라우터는 뷰를 띄우거나 전환하거나 닫는 등 그런 모든 일련의 뷰 이동 관련해서 담당합니다.
쉽게 정리하면 그냥 뷰 라우팅을 해준다~ 입니다.
그럼 이 요소들을 각자 정리해봤는데 감이 잘 안오네요.
어떤 플로우를 가지고 VIPER가 흘러가는지 한번 알아볼께요!
VIPER의 Flow 🎶
1️⃣ View에서 유저 인터랙션 등과 같이 새로 UI를 업데이트 하기 위한 액션이 발생
2️⃣ View가 Presenter에게 해줘~ 떼씀
3️⃣ Presenter가 Interactor에게 View가 새 데이터 빨리 달라는데? 해줘~ 떼씀
4️⃣ Interactor는 View 업데이트를 하기 위한 Data를 받아오거나 업데이트하기 위해서 비지니스 로직을 거침
5️⃣ Entity를 통해 업데이트할 데이터를 가져옴
6️⃣ Interactor가 가져온 Entity를 Presenter에게 납부
7️⃣ Presenter는 이 Entity를 View에게 상납
8️⃣ View는 결국 손안대고 코푼것처럼 상납받은 Entity를 가지고 UI 업데이트함잔인하네요.
결국 View가 갑이고 Presenter가 1차 하청, Interactor가 2차 하청 느낌이 나네요 😭
남일 같지 않아 슬픈 현실 😭
결국 이렇게 각 요소들의 역할과 상관관계를 정리해볼 수 있는데요.
그럼 이렇게 나눈 이유의 장점이 뭘까요?
VIPER 장점이 뭔데?
MVC에서는 기본적으로 View와 ViewController의 역할을 명확하게 딱 구분짓고 선을 긋기가 많이 어렵죠.
즉, 개발하다보면 ViewController가 뷰를 그리고 인터랙션도 처리하는 등 되게 비대해지고 다양한 일을 많이 하게 됩니다.
그렇기에 MVVM이나 TCA 등과 같은 아키텍쳐들이 각 요소들의 역할을 명확히 구분짓기위해 사용되죠.
그런것처럼 VIPER도 SOLID 원칙 중 S인 SRP(Single Responsibility Principle), 단일 책임 원칙을 지킬 수 있습니다.
즉, 클래스는 하나의 기능만 가지고 그 역할에 충실하는것처럼 이 구성 요소도 각자의 할일 역할에 충실하게 구분지어 나눌 수 있죠.
그렇기에 엮어 들어가는 부분이 적고 하나의 요소만 비대해져 다양한 역할이 혼잡되어 있는 상황을 피할 수 있습니다.
그럼 장점만 있나요?
단점도 있지 않을까요?VIPER 단점..?
제가 생각하기로는 VIPER도 그렇고 TCA나 RIBs 등등 이러한 아키텍쳐들도 장점만 있진 않죠.
VIPER도 비슷한 맥락으로 이렇게 확실하게 요소들을 구분하고 역할을 나눠준만큼 MVC에서는 모델과 VC 파일만으로 충분하고 다 VC에 구현해도 무방했다면, VIPER는 최소 저 요소들을 만들기만해도 파일은 5개가 됩니다.
즉, 이 아키텍쳐를 사용하기 위해서는 어떤 프레임워크든 그러하겠지만 따라야할게 많아집니다.
그렇기에 서비스가 큰 프로젝트는 확실히 템플릿을 지켜갈 수 있고 명확하게 나눠지기에 장점이 더 많을 수 있겠지만 비교적 정말 간단한 프로젝트 같은 경우 오히려 지켜야할것이 많기에 빠르게 쳐낼 수 있는 일도 그 규율을 따르다보니 개발 속도가 저하될 수 밖에 없긴하죠 🥲
물론, 추후 확장성, 유지보수 등과 같이 지금은 작더라도 미래에 점점 더 커질걸 대비한다! 라고 한다면 이견 없습니다 😉
다만 이것 외에도 추가적으로 구조에서 볼 수 있듯이 Presenter-View, Presenter-Interactor의 관계를 보시면 의존되어있죠?
그 말은 결국 양방향이라는 소리고 양방향의 순환 참조 등 겪을 수 있는 문제들을 조심해야 한다는 소리입니다.
양방향이기에 꼬일 수도 있고 오히려 코드 템플릿이 맞춰지지 않는다면 더 괴물같이 변할 수 있죠.
그런 단점을 보완하고자 TCA 같은 아키텍쳐가 유행하기도 하나 일단 패스~
그냥 현재까지 찍먹하고 있는 바로는 단점을 굳이 가져가자면 요렇다 정도인것 같아요!
그럼 실제 VIPER의 파일 구조가 어떻게 되는지 살펴보겠습니다 🙌
VIPER 파일 구조만 살짝 보기 👅
이번 포스팅에서는 정말 도입 맛보기라 실제 파일들에 어떤 코드들이 들어가는지는 이후 2탄에서 계속될 예정이고 이번에는 파일 구조를 어떻게 역할별로 가져가는지만 봐보겠습니다 😉
그냥 위에 구성 요소들 말한거 폴더랑 파일로 가볍게 구조만 정리해봤습니다!
간단하게 TodoList를 예제로 만들면서 한번 적용해보려구요 😃
TO BE CONTINUE
다음 포스팅부터는 진짜 하나씩 어떤 코드로 구성되어 굴러가는지 예제를 만들어보면서 진행해볼께요!
참고 레퍼런스
https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52
iOS Architecture Patterns
Demystifying MVC, MVP, MVVM and VIPER
medium.com
https://medium.com/swift-india/viper-architecture-example-in-ios-in-swift-4-6f656a441f7c
VIPER Design Pattern in iOS, Swift 5
Code with me in the VIPER design pattern.
medium.com
'VIPER' 카테고리의 다른 글
VIPER 뿌셔보기 (3) (16) 2023.08.10 VIPER 뿌셔보기 (2) (16) 2023.08.07