아키텍처 공부 amitshekhariitbhu/iOS-Viper-Architecture

 

 

 

이번에는 VIPER 아키텍처를 공부해보려고한다. 

예제는 깃헙에서 별이 많은 아래 코드로 공부해봤다. 

https://github.com/amitshekhariitbhu/iOS-Viper-Architecture

GitHub - amitshekhariitbhu/iOS-Viper-Architecture: This repository contains a detailed sample app that implements VIPER architec

 

VIPER 란..?

View, Interactor, Presenter, Entity, Router 앞글자 하나씩 따서, VIPER라한다.

 

VIPER의 정의가 다양한것 같다.
clean-architecture기반으로 재해석하여 만들어진 아킥테처라고 하는것 같은데,
실제 그것을 응용하여 프로젝트에 접목시키거나, 관련 VIPER 글을 보면, 아닌것 같다라는 느낌도 든다.

 

Entity는 Interactor에서 사용되는 단순데이터 모델이라고 설명하는곳이 있는데, clean-architecture 에서는 핵심업무규칙으로, 앱의 중요한 데이터모델을 담당한다고 한다. 앱의 전반적인 핵심Model인데 말이다.

 

어디서는 VIPER는 UI 구성 아키텍처라고도 한다.

 

clean-architecture의 핵심은 의존성을 분리하여 변화에 유연하게 대응한다라는 측면에서는 다양한 VIPER의 설명도 맞는듯하다.

 

사실 정답은 없고, 재해석하여 만든 패턴이므로, 공통적인 핵심만 일치한다면 괜찮지 않나 싶다.

 

 

해당 프로젝트의 VIPER구조

View

ViewController, View를 의미하며 화면에 보여주는 역할을 한다.
Presenter에 의존한다.

Interactor

비즈니스로직을 담당하는 역할을 하며,
Presenter에 의존하고있다. ( 콜백목적으로 )

Presenter

Interactor에 의존하여, Interactor에 데이터들을 요청하여 View가 보여줄수있는 데이터를 관리한다.

Entity

앱의 핵심 데이터 모델을 정의하고있다. ( Post)
Interactor들이 이 Post를 만들어낸다.

Router ( == Wireframe)

뷰 전환의 책임을 담당한다.
여기서 필요한 의존성들을 다 주입한다. ( View, Interactor, Presenter)

 

 

느낀점

아래느낀점은 통용되는 VIPER에 대한 느낀점이 아닌 이 프로젝트에서 사용된 VIPER의 개인적인 느낀점이다.

 

클린아키텍처 책을 읽고, 깃헙 iOS-Clean-Architecutres을 공부해서그런지 비교를 하게됐다.

 

아래느낀점들이 아쉬운점이 많아보이지만, VIPER라는 느낌이 어떤건지는 이해할수있는점에서는 좋은 예제 같다.

 

다이어그램

의존성 다이어그램

위에서 설명했듯이,  이 예제에서는 Router가 모든 요소들에 대해 의존하고있고, 관리하고있다 (의존성주입)

의존성 다이어그램 + 구현체 

( 열린화살표는 의존한다는 뜻(참조), 닫힌화살표는 구현했다는 뜻 )

Router가 보면 구현체를 다알고있다. 어쩔수없다 의존성을 넣어주는 객체이므로. 

하지만 각 프로토콜들은 프로토콜로만 의존하고있어, 의존성 역전이 다 적용됐다. 

 

독립적으로 작은단위로 개발 가능성 ?

VIPER 단위로 개발이 가능해보인다. (View, Interactor, Presenter, Router, Entity )
그 기준은 뷰단위인건지 아직 명확히 모르겠으나, 이 프로젝트는 영화목록과, 영화세부화면으로 두개로 나누었다.
VIPER & VIPER & VIPER 요렇게 블럭처럼 구성하여 개발가능해보인다.

 

 

🧐 어느프로젝트가 적절한가.. ? 

프로젝트의 성격에따라 그에 맞는 아키텍처를 선정해야한다고 하는데, 아직 그 기준을 정확히 모르겠다. 하지만 VIPER는 대규모 서비스에는 좋아보이는듯하면서도.... 각각의 VIPER들이 핵심적인 기능들을 공유한다면... VIPER가 적절할지... 잘모르겠다. ㅠ
좀 더 다른 분들의 예제케이스도 많이 공부해보고 실제로 적용도해보고 해야겠다.

Entity의 의존성

프레임워크 의존성에 대한 아쉬움 ?

Clean-Architectures관점에서 보면, Entity는 애플리케이션과는 독립적으로 존재할수있으며, 그것을 제대로 구현했다고 생각이드는 iOS-Clean-Architectures에서는 어떠한 프레임워크도 import하고있지않았다.
그런데, 여기서는 Entity를 CoreData를 사용한다고 이미 선언하고 있다.
CoreData도 세부사항일텐데, Entity에 바로 맞춘것은 아쉬워보인다.

DTO부재에 대한 아쉬움

여기서 사용된 Entity, PostModel이 전반적으로 모두 사용되고있다. View, Presenter, Interactor 모두 사용하고 있다. 이는 PostModel에 모두 의존적이라는것이고, PostModel은 변경하기가 어렵다는 뜻이다.
개인적으로는 View에서만큼은 View에서 사용할 모델을 따로 만들고 변환해주는 역할을 만든게 낫지않았을까 싶다.

 

Entity폴더의 아쉬움?

이 예제에서 사용된 Entity가 클린아키텍처의 Entity랑은 다른것 같다. 
VIPER 단위로 개발가능해보여서, PostList, Post에 각각 Entity를 만들어주는게 더 보기편하고, 독립적으로 개발할때도 더 좋지않을까?

 

지금은 Entity / PostDetail / PostList 로 구분이되어있는데, 

 

아래처럼 나누는게 더 좋아보인다. VIPER의 의도가 더 명확히 보이는것 같다. 

 

Interactor의 장단점?

UseCase의 부재

• UseCase가 없고, 축소버전을 Interactor가 하는것 같은데, (같진않고) Interactor가 presenter를 의존하고있다는점이 다르다.
• UseCase는 애플리케이션과는 독립적으로 존재할수있는건데, presenter를 의존하고있으니 UseCase라고 보기는 어렵다. Interactor의 기능을 컴플리션핸들러로 전달하게하여 Presenter모르게 하는게 더 나아보이는데..
• UseCase라는 폴더가 없어서, 프로젝트 폴더만으로는 이 앱의 의도를 파악하기가 어렵지 않나 싶다.

UI단위로 개발가능.. ?

• 장점은.. Presenter & Interactor 끼리 컴포넌트화하여 같이 독립적으로 개발가능해보인다.

Presenter의 의존성

Presenter가 Wireframe에 의존하고있다. Protocol로 의존하고있어서 의존성역전은 됐으나, protocol이름이 wireframe이라 너무 의존적으로 보인다.
PresenterProtocol이름으로 새로만들어서 하거나, closure형식으로 주입받는 형식이 더 뭔가 나아보인다.