Model View ViewModel

Model-View-ViewModel概念図。直線は直接的なAssociationを表し、破線は（例えば）Observer パターンを経た間接的なAssociationを表す。

Model-View-ViewModel (MVVM、モデル・ビュー・ビューモデル) はUIを持つソフトウェアに適用されるソフトウェアアーキテクチャの一種である。

MVVMはソフトウェアをModel・View・ViewModelの3要素に分割する。MVVMパターンはソフトウェアのプレゼンテーションとドメインを分離し、ソフトウェアの保守性・開発生産性を向上させる。

Model-View-ViewModelパターンはModel-View-Controller (MVC) パターンの派生であり、特にPresentation Modelパターンを直接の祖先に持つ。元来マイクロソフトのユーザインタフェースサブシステムであるWindows Presentation Foundation (WPF) や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やMVPパターンなどMVVMパターンよりも前に発生した他のドメインにも波及している。

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

さらに今日では、パターンはmodel-view-binder (MVB) としても記載されている。

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という言葉が提唱されたWindows Presentation Foundation (WPF)の世界でのMVVMにはPresentation Modelより一歩進んだ特徴がある。WPFでViewを担当するXAMLというXMLベースのDSLは非常に高機能で、Viewを完全にXAMLだけで実装する事やViewModelに対してViewを完全に抽象化する（異なったViewで差し替え可能にする）ことも可能となっている。

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

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

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

• XAMLベース
  • Windows Presentation Foundation (WPF)
  • Silverlight
  • Windowsランタイム (WinRT)
    • ユニバーサルWindowsプラットフォーム(UWP)
  • Xamarin.Forms
• android-binding
• Knockout.js
• AngularJS
• Vue.js

関連項目

• Model View Controller (MVC)

外部リンク

• Introduction to Model/View/ViewModel pattern for building WPF apps
• Model-View-ViewModel デザイン パターンによる WPF アプリケーション
• MVVMのModelにまつわる誤解
• android-binding - Android開発用のMVVM用ライブラリ