はじめに
この記事では、VIPERモデルについて簡単にまとめました。
⚠️当方初学のため認識違いがある可能性大です
誤りを見つけた際はコメントにて指摘していただけると幸いです🙇♀️🙇♂️
参考
この記事は、以下の情報を参考にして執筆しました。
VIPERモデルとは
（https://qiita.com/hicka04/items/09534b5daffec33b2bec から引用）
Router : 画面遷移を担当。
Presenter : 旗振り役。
Interactor : ビジネスロジックを担当。
Entity : データそのもの。
View : 見た目とユーザ操作を担当。
UIView and/or UIViewController : 見た目とその処理等を行う。
UIKit independent mediator: 仲介役。
Manipulates data and use cases : データとその処理を担当。
Owns and sends user actions : ユーザアクションの通知。
Owns and asks for updates : 処理、更新の依頼。
Knows about : 一方的に知っている。
Notifies : 通知。
Updates : 更新。
クリーンアーキテクチャをiOSアプリ開発用に再整理したもの
View , Interactor , Presenter , Entity , Router に役割を分けていてその頭文字を取ってVIPERと呼ぶ。
VIPERアーキテクチャの理念
依存性の分離
- 要素同士関心のない状態
- 互いにプロトコルで繋がる（プロトコルにのみ依存している状態）
- 実態は外部から差し込む(依存性注入)
単一責任の原則
- クラスの中身を変更する理由は複数存在しない（１言で説明）
→1ビジネスロジック = 1クラス
View
画面の更新とPresenterへのイベント通知を担当。
1ViewControllerに対して1protocolを切る。
Interactor
CRUD担当。
Presenter から依頼されたビジネスロジックを実施し、結果を返す。
import UIKit禁止（UIがどうなっているか気にしない）。
※循環参照にならないよう注意。
Pressenter
Viewから受け取ったイベントを元に別のクラスに依頼する。
Viewに対して画面の更新を依頼する。
Interactorに対してデータの取得を依頼する。
Routerに対して画面遷移を依頼する。
import UIKit禁止（UIがどうなっているか気にしない）。
Presenterには状態を持たせない（ハブに徹底）。
※状態を持たせてしまうとテストコードが書きにくくなる。
Entity
structでデータ構造を定義する。
import UIKit禁止（UIがどうなっているか気にしない）。
基本的にプロパティとイニシャライザのみ定義し、ロジックを持たないようにする。
Router
画面遷移とDI（依存性注入）を担当。
VIPERアーキテクチャの肝であり、他の有名アーキテクチャにないところ。
（他アーキテクチャでは画面遷移の処理はViewが請け負っており、コードの見通しが悪くなりがち。）
※画面生成は Router で行い、クラス内部で init() 等をしない。