Model View ViewModel

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

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パターンをWPFSilverlightのプラットフォームにより特化したものになるようにMVVMを検討しています。"

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

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

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

このパターンの顕著なJavascriptの実装がKnockout.jsです。

MVVMの構成要素[編集]

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

Model[編集]

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

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

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

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

脚注[編集]

  1. ^ PresentationModel
  2. ^ PresentationDomainSeparation

関連項目[編集]

外部リンク[編集]