Model View ViewModel

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動先: 案内検索
Model-View-ViewModel概念図。直線は直接的なAssociationを表し、破線は (例えば)Observer パターンを経た間接的なAssociationを表す。

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

元来マイクロソフト社のユーザーインターフェイスサブシステムである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パターンをWPFSilverlightのプラットフォームにより特化したものになるようにMVVMを検討しています。

MVVMパターンは、2006年11月21日にリリースされた.NET Framework 3.0に実装されたWPFSilverlightの両方をサポートするために考案された。しかし、MVVMパターンは[いつ?]ではより広く適用され、MVCMVPパターンなどMVVMパターンよりも前に発生した他のドメインにも波及している。

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

さらに最近[いつ?]では、パターンはmodel-view-binder (MVB) としても記載されている。

このパターンの顕著なJavaScriptの実装がKnockout.jsVue.jsである。

MVVMの構成要素[編集]

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

Model[編集]

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

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

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

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というXMLベースのDSLは非常に高機能で、Viewを完全にXAMLだけで実装する事やViewModelに対してViewを完全に抽象化する(異なったViewで差し替え可能にする)ことも可能となっている。

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

MVVMを採用可能なプラットフォーム[編集]

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

脚注[編集]

  1. ^ PresentationModel
  2. ^ PresentationDomainSeparation

関連項目[編集]

外部リンク[編集]