배경

지금까지 iOS 앱을 개발할 때, MVC 프레임워크를 이용하고 있는 케이스가 많았다고 생각합니다! !
(실제 나도 현장에서 MVC의 개발이 많았다・・・💦)

MVC를 사용하면 Controller의 비즈니스 로직이 커지고 꽤 어려워지고 관리가 어려워집니다!

그런 가운데, iOS의 개발 현장에서 태어난 것이, VIPER 입니다❗️

VIPER란?

VIPER는 각 레이어의 머리 글자 조합으로 VIPER라고합니다.

View

Interactor

Presenter

엔티티

Router

각 레이어의 관계

공식의 그림(잘 모르는···💦)

공식 iOS Project Architecture: Using VIPER 에서 인용했습니다.

자신이 읽고 관계도를 작성✨

어쩌면 이런 느낌 ... 💦
잘못되면 지적해 주세요. 곧바로 고쳐 ❗️

각 레이어에 대해

"View"

기본적으로는, 화면의 UI 표시, UI의 이벤트 수신을 실시한다.
또한 비즈니스 로직은 Presenter에 처리를 던집니다.

"Presenter"

DB 등의 데이터의 갱신, 화면 표시의 갱신, 화면 천이의 처리를 각 레이어에 던진다.

Router

화면 천이를 행한다.
화면 간의 데이터 전달에도 사용할 수 있습니다.

"Interactor"

각 유스 케이스에 대한 데이터 CRUD
또한 시스템의 비즈니스 로직과 동적 처리를 담당합니다.
Background 통신 주위 등도 포함

엔티티

데이터 정의하기
GETTER/SETTER

명명

역할
프로토콜 이름
실체명

View{ModuleName}View{ModuleName}ViewControllerInteractor{ModuleName}Usecase{ModuleName}Interactor
{ModuleName}InteractorDelegatePresenter{ModuleName}ViewPresentation{ModuleName}ViewPresenterEntity- ※1
{~~}Entity ※2
Router{ModuleName}Wireframe{ModuleName}Router

인용 그대로 팩 왔습니다 w

※1:Entity는 테스트 시에 교체할 ​​필요가 없을 만큼 단순한 구조이므로 프로토콜 불필요
※2:1개의 모듈로 복수의 Entity를 취급하는 경우도 있기 때문에

요약

화면 주위와 DB를 완전히 분리함으로써, 각각에 기능으로서의 역할을 갖게 할 수 있어, 간결하게 설계할 수 있는 것을 알았습니다.
또한 Interactor에 한해서는 독립형 디자인이므로 블랙 박스 테스트가 쉽습니다.

테스트 코드 (XCTest)에 대한 자세한 내용은 다음 기사를 참조하십시오 ❗️

부드러운 Swift 단위 테스트 ~ 테스트 가능한 클래스 설계 · 전편 ~
XCTest 입문 (Swift) ~UITest편~

인용

자세한 내용은 아래 기사를 참조하십시오 ❗️

iOS Project Architecture : Using VIPER [일본어]
VIPER 아키텍처 요약
VIPER 아키텍처로 제품의 iOS 앱을 1부터 만든 정리