Model-ViewModel-View の最近のイメージ

以前にも MVVM について記事にしたことがあったが、最近のイメージについて整理してみる。

基本的には、Model-ViewModel-View の 3 段構成である点については前の記事の通りなのだが、それぞれの部分において、抽象的ではなくより具体的な性質の違いが見えてきた。絵にすると次のような感じ：

Model

Model 部分はミキサーに材料を入れてジュースにするようなイメージで、最終的にひとつの結果の出力に到る。Perl や Python 等で手続志向のコンソールプログラミングをする時のようなイメージ。Web スクレイピング等で、データを加工するその複雑な処理過程をプログラミングすることになるが、時間の流れとしては一方向で、またデータオブジェクトも、成果物としては一つである（ミキサーの絵のように、入力される側の要素は、複数でも構わない）。

流れ的には一直線であるが、データの加工工程そのものに重要性がある。

ViewModel

ViewModel 部分は時間の流れ的には一方向ではあるものの、Model に生じた更新を伝播させて複数の View 用の LiveData オブジェクトに帰着させる流れを定義する。ここでは伝播が分岐したりし、さらに、オブジェクト同士の依存関係から、前後関係に留意しなければならないので、Model 部分よりは安易ではない。

例えば、View 側にさらすための LiveData オブジェクトが、あるリストとインデックスとそこからリストとインデックスに依存して取り出す一つの要素だったとする。何も考えずにバラバラにそれぞれを LiveData として定義しただけだと、インデックスが最後尾にあった場合に、リストが伸び縮みすると、要素を取り出す時に IndexOutOfBound エラーを引き起してしまう。そのため、まずはリストを更新し、インデックスが新しいリストのサイズに対して問題ないかをチェックして必要な場合は修正し、それからリストとインデックスに従って要素を取り出すという順序になるようにコードを記述する必要がある。つまり、1) リスト 2) インデックス 3) 取り出す要素 という 3 者の先後は必ず守らなければならないものであることがわかる。

View

ViewModel で非同期的な部分は吸収できているので、View 側では単純に無時間的な平面的なレイアウト要素として LiveData を埋め込んで使えばよい。View においては時間の「流れ」という側面は（Activity のライフサイクルを除いて）気にしなくていいが、ここではむしろ「流れ」というよりは、随時発生する UI イベントに対するハンドリングがコーディングの中心となる。