はじめに
Androidのアプリにおいて、これまではフレームワークを利用できていればよいといった感じでしたが、時代の流れやAndroidのライブラリの拡充によりアーキテクチャを考える機会が増えてきました。
世間では、様々なアーキテクチャが提唱されています。例えば、MVP、MVI、MVVM、クリーンアーキテクチャなどなど、人それぞれの設計で、アプリ開発を開発していくことになると思います。
しかし、増えすぎてしまい、どれを選んだらいいのかわからないということもあります。
今回は、今の所、優勢なMVVMの概要について簡単に説明します。
レガシーなアプリ開発とMVVMの違い
MVVM設計を単純に説明するのであれば、書籍などを読めば問題ありません。しかし、書籍では、MVVMの設計概念はわかるのですが、 何が嬉しいのか（メリット） が分かりづらいです。
このメリットが理解できれば、MVVMの概要を理解する近道になります。
まずは言葉の整理をしておきます。
MVVMは、「Model + View + ViewModel」を組み合わせた言葉です。
それぞれに役割が明確化されています。
それぞれの役割をまとめてみました。
| 用語 | 役割 |
|---|---|
| Model(M) | ドメイン領域を担います。ドメイン領域と言われると始めて聞いた方からすると意味不明です。 要はビジネスロジックやデータを格納するクラス（データクラスやエンティティ）、DAOなどの処理を担当する部分です。MVCで言うところののModelです。 |
| View(V) | ズバリ、見た目です。Androidであれば、レイアウトリソースファイルやそれをinflateしたものを考えておけばいいでしょう。XMLファイルで見た目を定義することが多いと考えられます。最近ではDSLで！ってこともあると思います。 |
| ViewModel(VM) | 一言で表すとビューの管理とイベント処理です。 主な作業は、以下の通りです。 ・Viewに表示するデータの管理 ・各種Viewのイベント処理 ・データの取得やビジネスロジックの呼び出し |
用語と役割がわかったところで、レガシーなアプリとMVVMによる設計を図で確認してみましょう。
図からも理解できるように、レガシーなアプリはすべてActivityに処理を記述していたため、Activityが巨大化する傾向にありました。
しかし、MVVMにすることにより、それぞれの処理を役割ごとに分割し、クラスを疎結合に保ちます。
ViewModelとActivityの比率
MVVMの概要が理解できると、次はこんなことに気がつくと思います。
このまま行けば、いずれViewModelが巨大化してしまうんでは無いだろうか？？と考えてしまいます。
上図を見るとなんとなく、ActivityとViewModelは1:1のようなイメージを抱きますが、そんなルールはありません。
必要に応じて、Activityに応じてViewModelを増やして問題ありません。
これらを図にまとめてみました。
ViewModelを増やすと再利用の可能性が出てきたり、ViewModelは巨大化せずにすみます。しかし、数が増えればメンテナンスにコストがかかることも忘れないでおいてください。
まとめ
MVVMは処理を明確にクラス分けすることにより、メンテナンス性を向上させる事ができます。
また、Activityの巨大化を食い止める事ができると考えてください。