iOS 設計

[iOS] iOSアプリケーションの設計を考える 2

今回はMVP, MVVM, Fluxについてです。 # MVP オブザーバー同期を使わずにフロー同期を使うため、ソースコードの流れを追いやすいのが特徴です。 個人的には一番理解しやすいので、このパターンが好きです。 iOSのアプリケーションにありがちなUIViewControllerのクラスが肥大化する問題を、Presenterと呼ばれるクラスを導入することで回避しつつ、テストも可能にします。 | 項目 | 説明 | | ----- | ----- | | Model | ビジネスロジック, BLE通信, データ | | View | UIに関係する処理, Actionの取得 | | Presenter | ModelとViewの橋渡し。 Actionを受けてModelを更新, Viewを更新する | 　　 ## メリット - データの流れが追いやすい - ViewControllerからロジックを引き剥がせる - テストしやすくなる ## デメリット - データの流れが冗長になりがち ## 所感 MVCと似ているので、一番とっつきやすいイメージ。 テストが導入しやすくなるので、ぜひ取り入れていきたいパターン # MVVM Model, View, ViewModelから構成するパターン。 本は.Netで使われていたパターン 特徴はViewModelはModelの変更をデータバインディングで受け取る点。 NotificationCenterやRxSwiftなどのフレームワークを使うことが多い。 MVPとの違いは、PresenterがViewの参照を保持するのに対して、ViewModelはオブザーバー同期でViewを更新する。 (ViewModelがViewの参照を持たない) | 項目 | 説明 | |-----------|-------------------------------------------------------------------------------| | Model | UIに関係しない純粋なドメインロジック, データ, BLE通信 | | View | ユーザ操作の受付、画面表示を担当. ViewController | | ViewModel | Viewに表示するデータを保持. Viewからイベントを受け取り、Modelの処理を呼び出す | 　　 ## メリット - ViewとViewModelを切り離せる - Modelを変更したらViewも自動的に更新される ## デメリット - RxSwiftなどを使う分、使い方を学ぶ初期コストが大きい - 設計思想を知っていないとコードを追うのが困難 ## 所感 RxSwiftを使う場合、フレームワークを使うことになるので、導入へのハードルが高い。 パターンを知っていない人に説明するのも大変なので、元から使っているプロジェクトでなければ導入することに躊躇する。 # Flux データの流れを単一方向にするパターン。 Action -> Dispatcher -> Store -> View | 項目 | 説明 | |------------|--------------------------------------------------------------------| | Action | 実行するためのTypeと 処理に紐ずくデータを保持する | | Dispatcher | Actionを受け取り、Storeに伝える。 | | Store | 状態を保持し、Dispatcherから伝わったActionとdataに応じて状態を更新 | | View | Storeの状態を監視し、変更に応じて画面を更新する | ViewからStoreに変更を伝える(ボタンが押されたなど)はDispatcherを経由して行う。 iOSで実現する場合は、enumを使ってActionを定義するとKeyを間違えたり、引数を柔軟に渡せるようになる ## メリット - データフローが単一なので、処理を追いやすい - ViewやActionなど役割が明確なので、どこに実装するべきか迷いにくい - Storeが状態を管理するのでViewControllerやViewから状態管理のコードを消せる ## デメリット - アプリの規模が大きくなってくるとActionが肥大化する - かといって、小さいアプリに対してはオーバーな気がする(実装するための手順が多い) ## 所感 データの流れが単一になるのは魅力を感じる。 プロジェクトに導入する場合は、設計の指針をまとめた方が良いと思う。(入力制限や画面遷移をどのクラスで行うかなど) # まとめ MVP, MVVM, Fluxについてまとめました。 実際にサンプルコードを作成することで、それぞれのパターンについてイメージを掴むことができました。 一番学んだことは、protocolなどを使って抽象化して、テスト可能にする点です。 UIのテストはできなくても、PresenterやActionを受け取った時の動作をテスト可能にすることで、その後の開発を迅速に進めることが可能になります。 そういった点で、もっと早くサンプルプログラムを作成して勉強しておけばよかったと思います。 次回はCleanArchitectureについてまとめます。 ## サンプルコード サンプルコードはこちら。 - [Github](https://github.com/k28/ios_design_pattern)