iOSアプリのアーキテクチャについて理解する

なぜ、アーキテクチャに拘る必要があるのか

アーキテクチャとは、アプリを綺麗に開発・継続的に運用していくための設計。
このアーキテクチャに沿わない形で開発すると以下のような障害が発生してくることになる。

• ファイルの肥大化
  • 1000行越えのViewControllerファイルができてしまったり、コードを追うことが困難に
• ロジックの煩雑化
  • 新規機能を付け足していくうちに、状態管理がめちゃくちゃに
    →機能の追加、改修が困難に。
• テストがしにくい
• 属人化が進み、プロジェクトの引き継ぎがし難い

etc...

設計一覧

MVC

処理流れ

1. Viewがユーザーの入力情報を受け付け、Controllerにアクションを渡す
2. アクションを受け取ったControllerがModelにデータの更新を依頼する。
3. ModelがControllerに処理の完了を通知し、ContollerからViewへ更新処理が走る

それぞれの役割

• View：表示、入出力
• Controller：入力にもとづくModelとViewの制御
• Model：データの保持、通信、ビジネスロジック

MVPは入力を受け付けるのがControllerではなく、Viewとなる

※図を参照する通り、MVCはControllerが肥大化しやすい。
→これを回避するために、ビジネスロジックをModelに移し替えるということがよく行われている。

MVP

それぞれの役割

• Model: データの保持、通信、ビジネスロジック

  • Presenterから移譲された処理を実行
    • API使うならAPIクラスを外からもらう
  • 処理完了後にpresenterに通知

• View: 表示、入出力

  • Modelを直接いじらない
  • Presenterにイベントを移譲
  • Presenterから貰った処理結果をそのまま表示するだけ

• **Presenter: ViewとModelの間で仲介役

  • Viewから受け取ったイベントをもとにModelに処理を移譲
  • Modelの処理結果を受け取り、Viewに通知

Presenterについて

• Viewで表示するために必要なデータをModelから受け取り、Viewへ渡してあげる仲介役。

• ライフサイクルやレイアウトに関する実装は含まない(UIkitに依存しない)。

Presenterの利点

ViewControllerをPresenterとして分割することができるので、ViewControllerの肥大化を防止できる。

ViewControllerとPresenterで役割ごとに分離できた為、テストがし易い

MVVVM

MVVMはModel、View、ViewModelで構成されます。Controllerがなくなり、ViewがView+Controllerの役割をします。そして、ViewModelがViewとModelを繋ぐ形になります。

それぞれの役割

• Model: データの保持、通信、ビジネスロジック
• View: 表示、入出力
• ViewModel: ビジネスロジックとUIを結びつける仲介者

ViewModelの役割

ViewとViewModelはバインディングという仕組みで繋がっていて、ViewModelがModelから変更点を受け取り、ViewModel自身の状態を更新します。

そのため、状態管理をしているViewModelがModelを監視しているので、条件によってViewやコンテンツを出し分けする処理の見通しが良いです。

MVVMの利点

モデルを書き換えると自動でViewが更新されるので、更新処理がまとまりやすく、読みやすい

MVPと同様、ViewModelにロジックが集中しているため、テストがし易い

参考記事