ViewModelって200種類あんねん

集まれSwift好き！Swift愛好会 vol.98

Transcript

1. ViewModelって 200種類あんねん 合同会社DMM.com アプリ開発室 野瀬田 裕樹（@ynoseda）
2. あなたは ViewModelとは何か 答えられますか？
3. 最初のViewModel
4. 最初のViewModel • 2005年にJohn Gossman氏がMVVMを発表 • その中でViewModelについて語られている
5. 最初のViewModel モデルに直接データバインドできるのはアプリケーションUIのごく一部に限られます。 特に、モデルが既存のクラスまたはデータスキーマであり、アプリケーション開発者が制御できな い場合はなおさらです。 モデルには、コントロールに直接マッピングできないデータ型が含まれている可能性が非常に高い です。UIは、ビューの厳密な定義では意味をなさないものの、モデルに含めるには特殊すぎる（あ るいは既存のモデルに含まれていない）コードで実装する必要がある複雑な操作を実行したい場合 もあります。 最後に、選択やモードなどのビューステートを配置する場所も必要です。 ViewModelはこれらのタスクを担います。 ViewModelとは「ビューのモデル」を意味し、ビューの抽象化と考えることができますが、View がデータバインディングに使用できるモデルの特殊化も提供します。 この後者の役割において、ViewModelには、モデル型をView型に変換するデータトランスフォー マーと、Viewがモデルと対話するために使用できるコマンドが含まれています。
6. ViewModelという名前の意味 • Viewを抽象化したもの • Viewがデータバインディングで利用できるように、 Modelを特化させたもの
7. 最初のViewModelの役割 • ModelをそのままUIにバインドできない問題を解決する • UIロジックを配置する場所を提供する • Viewの状態を保持する • ViewがModelを操作するためのインターフェースを提供する
8. MVVMといえば • Androidでは標準でViewModelというclassが存在します • 比較のため、AndroidでのVMの役割を確認してみましょう
9. Android ViewModel ViewModel クラスは、ビジネス ロジックまたは画面レベルの状態ホ ルダーです。 状態を UI に公開し、関連するビジネス ロジックをカプセル化しま す。 状態がキャッシュに保存され、構成が変更されてもそれが維持される ことが主なメリットです。 つまり、アクティビティ間を移動するときや、画面の回転などの構成 の変更に従うときに、UI でデータを再度取得する必要がありません。
10. Android ViewModelの役割 • ModelをそのままUIにバインドできない問題を解決する • UIロジックを配置する場所を提供する • Viewの状態を保持する（＋それをキャッシュする） • ViewがModelを操作するためのインターフェースを提供する
11. Android ViewModelの役割 • ModelをそのままUIにバインドできない問題を解決する → 通常RepositoryでUIが扱えるデータ型にする • UIロジックを配置する場所を提供する • Viewの状態を保持する（＋それをキャッシュする） • ViewがModelを操作するためのインターフェースを提供する → ビジネスロジックはUseCaseで提供し、VMがそれを叩く
12. 補足 Android公式のアプリアーキテクチャーガイドでは MVVMとは書いてません あくまでVMはUIレイヤーのState holdersの一例となっている
13. iOSにおけるMVVM • 正式なものはない • アプリごとによってViewModelの役割は異なる • VMについて見る前にMVVM以外のアーキテクチャーを確認しよう
14. Cocoa MVC • 伝統的なAppleのMVCアーキテクチャー https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html • UIロジック、データ取得、状態管理、画面遷移、ログ送信など多くの実装がVCに含まれてし まい、FatViewController問題を引き起こしがちだった User操作 描画更新 View View Controller データ更新 通知 Model
15. MVP • 特にApple公式でMVPに触れたことはないはずだが、 一部アプリでPresenterを採用している • MVPにはPassive View / Supervising Controllerの2種類がある • 今回の本題はMVVMなので詳細は割愛するが、 ViewにVCを含めて考え、UIロジック等をPresenterに実装する設計などが考 えられる View Presenter Model
16. VIPER • View + Interactor + Presenter + Entity + Routerの頭文字 • ビジネスロジックをInteractorに置き、画面遷移をRouterが担う • MVPにおけるPresenterの責務の一部が分割されていることが特徴
17. その他のアーキテクチャー • Flux/Redux系 FluxやReduxを参考に独自設計を採用しているケースがある • TCA（The Composable Architecture） 有名なので採用しているアプリも多いと思われる • MV（Model - View） AppleのサンプルリポジトリではViewとModelしかないことも多い
18. その他のアーキテクチャー • 最近は Presenter, ViewModel, ViewController のようなものを 持たない設計も多い • ViewModelが従来担おうとしていた責務が分割、整理されて 命名されている
19. iOSにおけるMVVM • MVVMもApple公式の定義はないため、 ViewModelの役割はプロジェクトごとに変わる
20. 例1：UIKit時代のVM • UIViewController + UIView + ViewModel + Model構成 • UIロジック、Viewの状態保持、Modelの操作IFの提供、 バインドできる形でのModelの提供などをVMに持たせられる • 最初のViewModelと近い役割での導入が期待できる
21. 例2：UIKit時代のVM • VC + View + VM + Repository + Model構成 • ModelをそのままUIにバインドできない問題はRepositoryが Publisherを公開するなどの形で委譲し、 ViewModelはその他の役割に専念する • ViewModelの肥大化に対応するため一部責務を切り出した状態
22. 例3：UIKit時代のVM • VC + View + VM + UseCase + Repository + Model構成 • VMはUIロジックを配置する場所を提供したり、 Viewの状態を保持したりするのに専念し、 その他をUseCaseやRepositoryなどに切り出した構成 • Androidにおける設計と近い構成になる
23. UIKit時代のMVVM • 同じ ViewModel という名前でもプロジェクトによって役割は様々 • UIロジック、状態管理、副作用管理、データ変換、画面遷移、etc • 全部盛りのVMもあれば、状態の保持に徹するVMもある • ViewModel は複数の責務の組み合わせで成り立つ
24. SwiftUI.View • SwiftUI.ViewはUIを実際に描画するわけではなく、 どのようにUIが構成されるべきかを記述したもの • Viewを抽象化したものであり、 状態を@Stateで保持してModelをバインドできるようになっている
25. SwiftUI.Viewは 状態を保持して Viewがbindできるようにする
26. 最初のViewModelのコンセプトと かなり近い存在では？
27. SwiftUI.ViewとViewModel • SwiftUI.Viewはほとんど最初のViewModelのコンセプトと同等 • ただ、 View に VM の責務を全部任せると辛いという気持ちもある • 例えば 「UIロジックを配置する場所を提供する」 「ViewがModelを操作するためのインターフェース」 ここら辺は切り出してView以外で実装しても良さそう
28. SwiftUI.ViewとViewModel • そうしてViewから切り出したものをViewModelと呼んでもいい
29. SwiftUI.ViewとViewModel • そうしてViewから切り出したものをViewModelと呼んでもいい （し、UseCaseとか別の名前で切り出してもいいし、
30. SwiftUI.ViewとViewModel • そうしてViewから切り出したものをViewModelと呼んでもいい （し、UseCaseとか別の名前で切り出してもいいし、 あとは全部Modelですって言ってもいいし、）
31. SwiftUI.ViewとViewModel • そうしてViewから切り出したものをViewModelと呼んでもいい （し、UseCaseとか別の名前で切り出してもいいし、 あとは全部Modelですって言ってもいいし、 表示ロジックだからPresenterですって言ってもいいかも）
32. まとめ • 元々のViewModelには色々な責務があった • iOSは公式のMVVMガイドなどはないので、 チームごとにViewModelが担う責務は違う • SwiftUIの登場でViewModelの責務の一部がViewに任せられるよう になり、チーム内でViewModelの責務を明確にする必要性が増した
33. 言葉遊びにならないように チームでViewModelの役割を 明確にしよう
34. ViewModelは1つではない 責務の組み合わせ次第で いくらでも形が変わる
35. だから ViewModelって 200種類あんねん
36. おわり