図解で分かるソフトウェアアーキテクチャ 「MVVM」のテスタビリティーと3つの特長：テストに強いソフトウェアアーキテクチャはこれだ！

アーキテクチャを選定する上で重要な視点の一つにテスタビリティ―がある。「MVVM」はMVCやMVPとどこが違い、何に優れているのか。図を交えて解説する。

[石黒 邦宏，デジタルハーツ]

　ソフトウェア開発においてさまざまな新しいアーキテクチャが提案されている中で、アプリ開発においてテストに強いアーキテクチャを紹介する本連載ですが、第3回の本稿では「MVVM」アーキテクチャについて解説いたします。

著者紹介：石黒 邦宏

デジタル・マジック・ラボでインターネット経路制御運用に関わり、オープンソースウェアで経路制御を実現する「GNU Zebra」を開発。1999年IP Infusionを共同設立し、CTOに就任。2009年Access CTO、2015年アプリックス CTOを経て、2018年デジタルハーツホールディングスCTOに就任。

「MVVM」の特長と仕組み

　「MVVM」（Model／View／ViewModel）とは、「MVC」や「MVP」に連なるアーキテクチャの一つで、2005年10月にマイクロソフトのジョン・ゴスマン氏が提案したものです。当時「Adobe Flash」（以下、Flash）が全盛の時代で、リッチなWebアプリケーションはFlashで実装するのが一般的でした。同時にWebテクノロジーも進化を遂げ、Webブラウザで非同期通信を実現する「Ajax」という言葉が生まれたのも同じ2005年でした。

MVVMのイメージ

　MVVMは、結果的にWPF（Windows Presentation Framework）や、マイクロソフトが開発したFlashライクなフレームワーク「Microsoft Silverlight」の基本アーキテクチャとして採用されました。しかし、ジョン・ゴスマン氏がMVVMを提案した時はまだWPFもSilverlightもリリースされていませんでした（WPFのリリースは2006年、Silverlightのリリースは2007年）。MVVMはまずアーキテクチャが提唱され、その後にそれを適用したプラットフォームが順次リリースされた歴史的に珍しいアーキテクチャなのです。

　MVVMの主眼は、複数の異なるUIプラットフォームを並行して使えるモダンな環境下でUIをHTMLベースで開発しても、またFlashなどのNon-HTMLベースの環境で開発しても耐えられるアーキテクチャの提案にありました。

　開発時にデザインとロジックを明確に分離してモダンで高度なアプリ開発を行うためという観点では、当時すでにソフトウェア開発者マーティン・ファウラー氏による「Presentation Model」（以下、PM）が存在していました。

　MVVMはマーティン・ファウラー氏のPMのアーキテクチャを敷衍（ふえん）しつつも、WPFやSilverlightなどの複数UIプラットフォームをサポートする過程の中で、Data Bindingやイベントドリブンのアーキテクチャといった新しいアイデアを生み出しました。

　その後、Android OSの6番目のメジャーアップデート「Android 6.0 Marshmallow」以降Data Bindingが全面的に採用され、Android開発にはなくてはならないものとなりました。またMVVMは、イベントドリブンのプログラムインタフェースを徹底していますが、この考え方が、のちのち「Flux」を生み出す下地になったと考えられます。

「テスタビリティー」から考えるMVVMアーキテクチャ

　では、本連載のテーマである“テスタビリティー”という視点から見た場合はどうでしょうか。

　MVCやMVPの場合、ModelやViewのインタフェースを呼び出して戻り値を確認するところから始めます。しかし、MVVMの場合は、MVCやMVPのようにViewのインタフェースが存在しないため、代わりにData Bindingを使います。

　MVVMは、Data Bindingの接続ポイントを切り替えることでテストを実施でき、実装の切り替えも容易です。また、Data Bindingは基本的には単方向のデータ反映の仕組みなので、従来のテストとは違ったテスト戦略を考える必要があります。

MVC／MVPとMVVMのテストイメージ

　上記の図のように、MVVMはモジュール呼び出しの戻り値はあまりなく、MVCやMVPよりもむしろ「Flux」アーキテクチャと近い側面を持っていると言えます。そのため、MVVMはMVCやMVPのような関数呼び出しと戻り値のチェックをするテスト方法はあまり有効ではなく、イベントドリブンのテスト戦略が必要になります。

MVVMの特長まとめ

・「View」の独立性が高いアーキテクチャである

・コード量は比較的少なく、変更への耐性もあり、テスタビリティにも優れている。ただし、イベントドリブンのアーキテクチャのため、それに対応したテスト戦略が必要になる

・異なったUIを持つ複数のアプリを同時に実装したい場合やViewの変更が多いアプリケーションを開発する場合に向いている

＜訂正＞（2019年9月9日10時）

本稿初出時に記載の「MVVM」の各モジュールの役割につきまして、図版「MVVMのイメージ」において「Model：データモデル」「View：プレゼンテーション」「ViewModel：ビジネスロジック」と記載しておりましたが、ビジネスロジックを担うモジュールについては、開発者によって考え方が異なる可能性があるため、「MVVMのイメージ」の図版を修正しました。また、それに伴い一部の文章を修正しました。