背景
いままでiOSアプリを開発する時、MVCフレームワークを利用しているケースが多かったと思います！！
(実際私も現場でMVCの開発が多かった・・・💦)
MVCですと、Controllerのビジネスロジックが肥大化し、かなり見づらくなり、管理もしずらくなります!!
そんな中、iOSの開発現場で生まれたのが、VIPERです❗️
VIPERとは？
VIPERは、各レイヤーの頭文字の組み合わせで VIPER と呼びます。
- View
- Interactor
- Presenter
- Entity
- Router
各レイヤーの関係
公式の図(よく分からなかった・・・💦)
公式 iOS Project Architecture: Using VIPER から引用しました。
自分が読み取って関係図を作成✨
たぶん、こんな感じ・・・💦
間違ってたら指摘ください。すぐに直します❗️
各レイヤーについて
「View」
基本的には、画面のUI表示、UIのイベント受信を行う。
また、ビジネスロジックは、Presenterへ処理を投げる。
「Presenter」
DB等のデータの更新、画面表示の更新、画面遷移の処理を各レイヤーへ投げる。
「Router」
画面遷移を行う。
画面間のデータの受け渡しにも利用できる
「Interactor」
ユースケースごとにデータのCRUDをする
また、システムのビジネスロジックや動的な処理を担う
Backgroundな通信周りなども含む
「Entity」
データの定義を行う
GETTER / SETTER
命名
| 役割 | プロトコル名 | 実体名 |
|---|---|---|
View |
{ModuleName}View |
{ModuleName}ViewController |
Interactor |
{ModuleName}Usecase |
{ModuleName}Interactor |
{ModuleName}InteractorDelegate |
||
Presenter |
{ModuleName}ViewPresentation |
{ModuleName}ViewPresenter |
Entity |
- ※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から作ったまとめ