Model View ViewModel

Model View ViewModel(モデル・ビュー・ビューモデル;MVVM)は、独自のGUI(グラフィカルユーザーインターフェース)を持つアプリケーションソフトウェアを、以下に述べるようなModel-View-ViewModelの3つの部分に分割して設計・実装するソフトウェアアーキテクチャパターンである。MVC(Model-View-Controller)の派生パターンであり、特にPresentation Model^[1]パターンを直接の祖先に持つ。MVVMを考慮してアプリケーションを開発する目的は、他のMVC系のパターンと同様にアプリケーションの「プレゼンテーションとドメインを分離^[2]」する事で、アプリケーション開発における保守性・開発生産性に寄与する事である。

元来マイクロソフト社のユーザーインターフェースサブシステムである WPF(Windows Presentation Foundation)やSilverlightの世界で生まれた考え方ではあるが、現在はAndroidやウェブブラウザ上でのJavaScriptの世界でもMVVMの利用は広がっている。

沿革

Microsoft MVPのJosh Smithのリポートより

"2005年に、マイクロソフトのWPFおよびSilverlightアーキテクトであったJohn Gossmanが自身のブログでModel-View-ViewModel（MVVM）パターンを発表しました。MVVMとFowlerのプレゼンテーションモデルは、両方ともビューの状態と動作を含んだ形でビューを抽象化しています。Gossmanはユーザインタフェースの作成を簡素化するために、WPFの活用コア機能への標準化された方法としてMVVMを導入し、一方、FowlerはビューのUIプラットフォームに依存しない抽象化を作成するための手段としてプレゼンテーションモデルを導入しました。その意味で、一般的なPMパターンをWPFとSilverlightのプラットフォームにより特化したものになるようにMVVMを検討しています。"

MVVMパターンは、2006年11月21日にリリースされた.NET Framework 3.0に実装されたWPFとSilverlightの両方をサポートするために考案された。しかし、MVVMパターンは今ではより広く適用され、MVCやModel View Presenter (MVP)パターンなどMVVMパターンよりも前に発生した他のドメインにも波及している。

WPFに取り組んでいる何人かのMicrosoftアーキテクト(クリエーターのJohn Gossman、Microsoft MVPのJosh Simith、MicrosoftプログラムマネージャーのKarl Shifflett）はMVVMについてオンライン上で幅広く情報発信している。

さらに最近では、パターンはmodel-view-binder（MVB）としても記載されている。

このパターンの顕著なJavascriptの実装がKnockout.js、Vue.jsである。

MVVMの構成要素

MVVMでは、プログラムを3つの要素、Model(モデル)、View(ビュー)、ViewModel(ビューモデル)に分割する。

Model

アプリケーションのドメイン(問題領域)を担う、そのアプリケーションが扱う領域のデータと手続き（ビジネスロジック - ショッピングの合計額や送料を計算するなど）を表現する要素である。

多くのアプリケーションではデータの格納に永続的な記憶の仕組み（データベースなど）が使われていたり、サーバが別途存在するアプリケーションではサーバ側との通信ロジックなどが含まれている。MVVMの概念ではMVCの概念と同様に、データの（UI以外の）入出力は取り扱わないので、強いて言うならばそれらはModelの中に隠蔽されると考えられる。

一般的にModelはドメインを担当すると言われるがこの言葉だけをもってModelの役割を想像するのは難しい。たとえばクライアントサーバモデルのアプリケーションのクライアントアプリケーション側は、そのドメインそのものがプレゼンテーションになっている。アプリケーションをプレゼンテーションとドメインに分けて考えようとした際にはこの事が混乱の一因となっている。Modelの役割は、後述するViewとViewModelの役割以外の部分と考えるのが妥当である。

ModelはViewの描画について知らないし、知る必要もない。ここで重要なのは、Modelは描画について関わらないだけで、Viewの見た目、装飾についての情報を保持したりするのはMVVMパターンとして何の問題も無いということである。つまり、そのアプリケーションが背景色や文字色、コントロール間の余白といった表示をカスタマイズできる場合、その背景色や文字色や余白のサイズを保持するのはModelである。ただし上述した通りModelは描画には関わることは無く、その情報を元に実際に描画するのはViewの役目である。(もちろんこのModelの情報はViewModelを経由してバインドされる。)

View

アプリケーションの扱うデータをユーザーが見るのに適した形で表示し、ユーザーからの入力を受け取る要素である。すなわちUIへの出力とUIからの入力を担当する。MVVMにおけるViewは、後述するViewModelに含まれたデータをデータバインディング機構のようなものを通じて自動的に描画するだけで自身の役割を果たす。Viewそのものに複雑なロジックと状態を持たないのがMVVMのViewの特徴である。そのためテンプレートエンジンや宣言型のDSL(ドメイン固有言語)にViewを委譲する形のプラットフォームと非常に相性がよくなる。

ViewModel

Viewを描画するための状態の保持と、Viewから受け取った入力を適切な形に変換してModelに伝達する役目を持つ。すなわちViewとModelの間の情報の伝達と、Viewのための状態保持のみを役割とする要素である。Viewとの通信はデータバインディング機構のような仕組みを通じて行うため、ViewModelの変更は開発者から見て自動的にViewに反映される。

Presentation Modelパターンとの違い

MVVMと同様にMVCの派生パターンであり、アプリケーションをView - Presentation Model - Modelに分割する形のPresentation Modelパターンというパターンがある。 Presentation ModelパターンのPresentation ModelはMVVMのViewModelと同様にViewの状態を保持し、ViewはPresentation Modelの状態をデータバインディング機構のような仕組みを通じて自動的に描画するのみである。一見MVVMとの区別はつかないが、もともとMVVMという言葉が提唱されたWPFの世界でのMVVMにはPresentation Modelより一歩進んだ特徴がある。WPFでViewを担当するXAML(Extensible Application Markup Language)というXMLベースのDSL(ドメイン固有言語)は非常に高機能で、Viewを完全にXAMLだけで実装する事やViewModelに対してViewを完全に抽象化(異なったViewで差し替え可能に)することも可能となっている。

しかし2012年4月現在、XAMLを使用するWPFなどのテクノロジ以外で使用されるMVVMは実質Presentation Modelと変わらず、Viewの抽象化などは出来ない。

MVVMを採用可能なプラットフォーム

MVVMではその構成上、ViewとViewModelの間の情報を開発者が手動で同期しなければならないようなプラットフォームでは非常に開発者の負担が大きくなり、メリットが発揮しにくい。そのためデータバインディング機構のような仕組みを持つプラットフォームか、既存のプラットフォームにデータバインディング機構のような仕組みを拡張したプラットフォームで採用されている。

脚注

外部リンク

Introduction to Model/View/ViewModel pattern for building WPF apps
Model-View-ViewModel デザインパターンによる WPF アプリケーション
MVVMのModelにまつわる誤解
MVVMパターンの常識 ― 「M」「V」「VM」の役割とは？
android-binding - Android開発用のMVVM用ライブラリ
Knockout.js - Javascript開発用のMVVM用ライブラリ
Vue.js - Javascript開発用のMVVM用ライブラリ

[1] PresentationModel

[2] PresentationDomainSeparation

[1]

[2]

沿革