[iOS] 아키텍쳐 VIPER 패턴

 

 

 

VIPER 구성도

 

 

 

 

항목	내용
View	Presenter의 요청에 따라 표시하거나, 사용자 입력을 Presenter로 보내는 작업을 진행합니다.
Presenter	Interactor로부터 데이터를 가져오거나, View로 보내기 위한 데이터를 보내줍니다.    이외에도 다음 화면으로 전환을 하는 Router를 이용할 때, View의 요청을 받기도 합니다.
Interactor	Presenter의 요청을 받아 Entity 객체의 데이터를 가공하여 Output하는 로직 처리를 담당하고 있습니다.
Entity	모델 객체입니다.
Router(WireFrame)	화면 전환을 담당하며, 전환 시기(When)는 Presenter가 알고 있고 해당 부분은 어떻게(How)를 담당합니다.

 

 

이렇게 각자의 역할이 분할되어있어 해당 로직의 문제가 있을 때 빠르게 찾을 수 있습니다.

 

 

물론.. 뷰 하나를 만들기 위해서는 이러한 작업들을 처리해야하지만요..

 

저는 아래와 같이 프로토콜을 제작해 이용하고 있습니다.

 

protocol ViewProtocol: AnyObject {
    var presenter: PresenterProtocol? { get set }
    
    // Func
}

protocol WireFrameProtocol: AnyObject {
    static func createView() -> UIViewController

    // Func
}

protocol PresenterProtocol: AnyObject {
    var view: ViewProtocol? { get set }
    var interactor: InteractorInputProtocol? { get set }
    var wireFrame: WireFrameProtocol? { get set }
    
    // Func
}

protocol PresenterOutputProtocol: AnyObject {
    // Func
}

protocol InteractorProtocol: AnyObject {
    var presenter: PresenterOutputProtocol? { get set }
    
    // Func
}

 

 

또한 Presenter의 View나 Interactor의 Presenter 등을 참조할 때는 weak를 이용하여 약하게 참조하고 있습니다.

 

그리고 View에 Present 시 각자의 역할을 초기화 하는 작업은 wireframe에서 진행하고 있습니다.

 

view.presenter = presenter
presenter.view = view
presenter.wireFrame = wireFrame
presenter.interactor = interactor
interactor.presenter = presenter

 

 

또한 작업을 하면서 여러 예제를 찾아보면서 DataManager를 따로 제작하는 소스도 확인해봤습니다. 이러한 DataManager도 과연 프로토콜에 같이 채택해서 하는 것이 맞는 것일까? 란 생각이 있었는데 만약 정말 큰 데이터를 해당 뷰에서만 작업해야하는 경우나 그러한 데이터를 가공해야한다면 채택하는 것이 괜찮은 것 같습니다. 그 외에는 하나의 싱글톤으로 만들어 관리하는 것이 더 좋을 것 같은 생각이 드네요.

 

 

마지막으로 해당 패턴의 장점을 간단하게 말한다면...

 

  1. 재사용성과 테스트용이함을 위해 코드를 분리할 수 있습니다.
  2. 앱 컴포넌트를 분리할 수 있습니다.
  3. 새 기능을 추가하기 쉽습니다.
  4. UI 로직이 비지니스 로직으로부터 떨어져있기 때문에 자연스럽게 테스트를 만들기 쉬워집니다.