MVVMパターンと他のUIパターン

既存のイベント駆動開発のWPF/Silverlightでの問題
MVC系パターンとMVVMの関係について
そもそもWPF/Silverlightで書くという事
 WPF/Silverlightは、既存のUI技術(Windows
Forms/ASP.NET)より高い表現力を持つからこそ採
用されます
 既存のUIより高い表現力を持つという事は？
 既存のアプリケーションより、UIに関わる機能の割合
が増えます。
既存のイベント駆動型開発では
なぜWPF/Silverlightの開発は難しいか？
イベント駆動開発 – イベントハンドラ
 前述の通り、WPF/Silverlight開発ではUIの挙動に
関わるコードの割合が増えます。
 イベント駆動開発を行った場合、UIのコードビハイ
ンドは大幅に「業務ロジック呼出をしない」イベン
トハンドラが増える事になります。
Windowサイズ変更
子のインスタン化待ち
論理ツリー走査
Windowサイズ変更時
業務ロジック呼出A
業務ロジック呼出Ａ
クリック時に色を変える
業務ロジック呼出B
進捗表示
VisualTree走査
コード量
増大
クリック時に色を変える
進捗表示
業務ロジック呼出B
DispatcherTimer
イベント駆動開発 – コントロールの仮想化
 また、WPF/Silverlightでは
WindowsForms/ASP.NETに比べてコレクションコ
ントロール(Grid/List/TreeView)などの仮想化が徹
底的に進んでいます。
こんなTreeView・・・
神奈川県をチェックしたら、子の市区町村にも
チェックを入れたい！
イベント駆動開発 – コントロールの仮想化
 また、WPF/Silverlightでは
WindowsForms/ASP.NETに比べてコレクションコ
ントロール(Grid/List/TreeView)などの仮想化が徹
底的に進んでいます。
こんなTreeView・・・
Window Formsなら、
イベントハンドラで簡単！
Webなら、
Javascriptで簡単！
神奈川県をチェックしたら
子の市区町村にも
チェックを入れたい！
しかしWPFだと・・・・
イベント駆動開発 – コントロールの仮想化
 また、WPF/Silverlightでは
WindowsForms/ASP.NETに比べてコレクションコ
ントロール(Grid/List/TreeView)などの仮想化が徹
底的に進んでいます。
こんなTreeView・・・
TreeViewを展開するまで
子のチェックボックスの
インスタンスがありません！
神奈川県をチェックしたら
子の市区町村にも
チェックを入れたい！
(デフォルト)
イベント駆動開発 – コントロールの仮想化
 また、WPF/Silverlightでは
WindowsForms/ASP.NETに比べてコレクションコ
ントロール(Grid/List/TreeView)などの仮想化が徹
底的に進んでいます。
こんなTreeView・・・
では、どうする？
まさか、
子コントロールのインスタンスが
できるまで別スレッドで待ちますか？
神奈川県をチェックしたら
子の市区町村にも
チェックを入れたい！
イベント駆動開発 – コントロールの仮想化
 また、WPF/Silverlightでは
WindowsForms/ASP.NETに比べてコレクションコ
ントロール(Grid/List/TreeView)などの仮想化が徹
底的に進んでいます。
こんなTreeView・・・
神奈川県をチェックしたら
子の市区町村にも
チェックを入れたい！
WPFなら
データバインド
で対処します
データバインディング
は、WPF/Silverlight
の前提技術です
イベント駆動開発 – コントロールの仮想化
 また、WPF/Silverlightでは
WindowsForms/ASP.NETに比べてコレクションコ
ントロール(Grid/List/TreeView)などの仮想化が徹
底的に進んでいます。
WPF/Silverlightでイベント駆動開発をしていると、
ほぼ必ず、UIの制御方法が混在します！
イベントハンドラによる制御と、
データバインドによる制御と・・・
イベント駆動開発 – まとめ
 WPF/Silverlightでのイベント駆動開発は、コードビハイ
ンドのメソッド量が大幅に増えます
 もともとイベント駆動開発には、「イベント処理順によ
るイベントハンドラの呼び出し順がコードから見えな
い」という問題がありますが、それがより顕在化します。
 テストが困難です。手法が制限されます。
 イベント処理順に依存したコードの保守で苦労した経験
はありませんか？
 また、イベントハンドラだけにUIの制御を統一するのは
ほぼ不可能です
イベント駆動開発
コードビハインドのイベントハンドラの数は増大し、
コントロールの仮想化が進んだ事によって、
イベント発生順に加えてインスタンス化のタイミング
まで把握しなければならず、
イベントハンドラによるUI状態の制御と、データバイ
ンドによるUI状態の制御が混在する・・・
そんなコードを保守したいですか？
そもそもそんなコードを書けますか？
より機能の増えたUIで！
MVC(Model-View-Controller)系はWPF/Silverlightに適して
いないの？
MVC系パターン
 色々な派生があります。
 MVP/プレゼンテーションモデル/アプリケーション
モデル
 詳細は@matarilloさんのページに
 matariilo.com UIパターン
 http://matarillo.com/general/uipatterns.php
 最大の目的はビジネスロジックに対するViewの抽
象化！
 各種派生パターンも、上記目的を果たすために基盤
技術の変化などに伴ってカスタマイズされてきただ
けであって、決してお互いに相反するものではあり
ません！
MVCパターン系
 「MVVMパターンは、MVC/MVPと比べてどういっ
たメリットがあるんでしょうか？」という声をたま
に聞きます
 MVC系の目的は、究極の所、ビジネスロジックに対
するViewの抽象化というだけです。この目的はUI設
計パターンとしてはきわめて汎用的であり、目的を
同一にするパターンはもともと相反しません。
 大事な事なのでもう一度いいます。
 MVVMパターンはMVC系パターンです。
ではなぜMVC/MVPパターンじゃないの？
 MVVMパターンという言葉が生まれた事で、
MVC/MVPパターンはWPF/Silverlightに適していな
いのだという思い込みが浸透しつつあるように思え
ます。
 おそらくは、MVC/MVPをWPF/Silverlightの基盤に
合わせて適用しようとするとMVVMにならざるを得
ないというだけの事です。MVC/MVPを定義通りに
適応可能か見ていきます
※MVC/MVPなどのGUIパターンには各種派生・流派
があるため、今回は比較的シンプルな定義に沿ってみ
ていきます。
MVC
古典的MVC
Controller
View
Model
⑤更新
MVC
古典的MVC
Controller
View
Model
⑤更新
MVC
古典的MVC
リッチクライアント開発環境
でのコントロールは、View
とControllerの機能を併
Controller
せ持つ事が多いため、
ViewとControllerを分
けて考えるメリットがそ
もそも少ない
View
Model
⑤更新
MVC
ViewはModelの監視のみが、遷移のトリガーとな
古典的MVC
るため、Modelに所属しない情報(非ビジネスドメ
インロジック)を元にViewは状態遷移できません
Controller
そもそも古典的なMVCは、非ビジネスドメインロ
ジックを保持する場所がありません
(MVCがそもそも抱える問題)
View
神奈川県をチェックしたら
子の市区町村にも
チェックを入れたい！
Model
⑤更新こういったModelまで届かない
ロジック・状態を持つ場所がありません
MVC
古典的MVC
View
また、②と④が分離している事
で、WPF/Silverlightの
TwoWayデータバインディン
Controller
グ機構を使用できません。
TwoWayデータバインディング
が使えないと、たとえばWPFで
標準で用意されたデータ検証の
仕組み(ValidationRules)を使用
できません。
Model
⑤更新
MVP
 MVP
Presenter
View
Model
⑥Modelの変化を受け
更新
MVP
 MVP
Presenter
Presenterは、MVCの問題であった「非ビ
ジネスドメインロジック」を担当する場所
として機能します。
View
Model
⑥Modelの変化を受け
更新
MVP
こういったシンプルな
MVPは、シンプルなMVC
Presenter
以上にGUIコントロール
の存在が、各役割の分担
を複雑化させます。
 MVP
View
GUIコントロールは、②
と④の役割を分担するの
も妨げるでしょう。
Model
⑥Modelの変化を受け
更新
ではWPF/Silverlightの様にModel
とController(あるいはPresenter)
を分離するメリットがない場合
は・・・？
PM
 Presentation Modelパターン
 MVC(MVP)にて、実装技術に依存してViewと
Controller(Presenter)を分離するメリットが見当た
らない場合に適応
ViewはPresentationModelを
レンダリングするだけ
View
監視
Presentation
Model
Model
監視
ViewとPresentationModelは
綿密に同期するため、データバインド機
構などがないと大変
PM
 Presentation Modelパターン
これがほぼ
MVVM
 MVC(MVP)にて、実装技術に依存してViewと
Controller(Presenter)を分離するメリットが見当た
らない場合に適応
ViewはPresentationModelを
レンダリングするだけ
View
Presentation
Model
Model
今までのパターンで一番
監視
監視
WPF/Silverlightに
ViewとPresentationModelは
妥当ですよね？
綿密に同期するため、データバインド機
構などがないと大変
MVC系パターン – まとめ
 MVC/MVPは、諸派あるが、そもそも諸説あるとい
う捉え方がおかしい。実装テクノロジ中立ではない
から、実装テクノロジごとに各パターンの実装があ
るだけ。
 WPF/SilverlightではシンプルなMVC/MVPを適
用する事は難しいし、要件を満たしにくい
 PresentationModelパターンが妥当
 PresentationModelパターンをWPF/Silverlight
の基盤に合わせて構築しなおしたのがMVVMパター
ン！
MVVMパターン
 Model/View/ViewModelパターン
 PresentationModelパターンを、WPF/Silverlightの
基盤を使用して実装の制約を追加し、進化させたも
の
 PresentationModelとViewの同期の仕組みを、
WPF/Silverlightの基盤を利用する仕組みに変更
 PrensentaitonModel = ViewModel（ほぼ）
View
ViewModel
Model
PresentationModelパターンとの違い
 PresentationModelパターンは、Viewと
PresentationModelを綿密に同期させる必要がある。
しかし、PresentationModelはViewを参照すべきで
はない
 ViewはPresentationModelを監視している
 本来PresentationModelパターンは、Viewを薄く、
PresentationModelのレンダリング機能のみと留め
る事で、PresentationModelがViewを参照する事な
く、Viewとの疑似相互アクションを実現している
View
Presentation
Model
PresentationModelが
変化する度にViewのレ
ンダリングが行われる
イメージ？
PresentationModelパターンとの違い
 同様にMVVMパターンは、ViewとViewModelを綿
密に同期させる必要がある。しかし、ViewModelは
Viewを参照すべきではない
 ViewはViewModelを監視している
 ViewからViewModelへの通知は、リフレクション
によって行われる。ViewModelからViewへの通知
は、イベントによって行われる。
 WPF/Silverlight基盤を利用した相互作用
リフレクション
ViewModel
View
イベント発行
PresentationModelパターンとの違い
 MVVMパターンでのViewとViewModelの相互機能
に使われるリフレクションとイベントは、基本的に
データバインディング機構によって隠ぺいされてい
る。
 開発者がリフレクションとイベント、Viewと
ViewModelの相互同期の仕組みにについて意識する
必要は無い。
View
データバインディング
ViewModel
なぜ隠ぺいするのか？- Interactionのリスク
 もともとオブジェクトに設計パターン用の責任を持
たせた場合、相互作用(Interaction)は設計パターン
そのものを崩壊させやすい
Presenter
例えばMVPのここ・・・
もし④がIF経由じゃな
かったら・・・・
View
なぜ隠ぺいするのか？- Interactionのリスク
 もともとオブジェクトに設計パターン用の責任を持
たせた場合、相互作用(Interaction)は設計パターン
そのものを崩壊させやすい
Presenter
ViewとPresenterが
相互依存！？
Viewに書くべきロジック・
Presenterに書くべきロジック
をきちんと分離するのは難しく
View
なるでしょう！
なぜ隠ぺいするのか？- Interactionのリスク
 もともとオブジェクトに設計パターン用の責任を持
たせた場合、相互作用(Interaction)は設計パターン
そのものを崩壊させやすい
Presenter
ＭＶＰパターンでは、④
をインターフェース経由
と規定する事により、
疎結合とし、相互依存の
リスクを軽減しています
View
なぜ隠ぺいするのか？- Interactionのリスク
 もともとオブジェクトに設計パターン用の責任を持
たせた場合、相互作用(Interaction)は設計パターン
そのものを崩壊させやすい
Presenter
それではInterface経由なら
パターンを守れる？？？
View
なぜ隠ぺいするのか？- Interactionのリスク
 もともとオブジェクトに設計パターン用の責任を持
たせた場合、相互作用(Interaction)は設計パターン
そのものを崩壊させやすい
Presenter
PresenterがViewをキャストしてイ
ンスタンスにしてしまえばViewを直接
いじれてしまうし・・・・
どうしても規約ベースの管理にならざ
View
るを得ない・・
じゃあ
理想は・・・・？
設計パターンとそのインフラが、
開発者の実装がパターン
からはずれないよう制約
する事が望ましい！
なぜ隠ぺいするのか？- MVVMのInteraction
 MVVMパターンの相互作用(Interaction)
リフレクション
ViewModel
View
イベント発行
リフレクションとイベントによるInteraction
がWPF/Silverlightの基本です
これ、隠蔽せずに開発したら・・大変な事に
なりますよね？
なぜ隠ぺいするのか？- MVVMのInteraction
 だからWPF/Silverlightは、
View
データバインディング
ViewModel
データバインディングというインフラの機構とし
てリフレクションとイベントを隠ぺいし、
リフレクションとイベントを開発者に意識させ
ず・自由に使わせずという形を実現しました！
なぜ隠ぺいするのか？- MVVMのInteraction
 MVVMパターンはWPF/Silverlightデータバインディ
ング機構に加えて、InteractionMessageという仕組
みも加えて、イベントとリフレクションを徹底的に
隠蔽します
データバインディング
View
ViewModel
InteractionMessage
なぜ隠ぺいするのか？- MVVMのInteraction
 データバインディングとInteractionMessageは、開
発者がパターンを破壊するコードを記述する事をイ
ンフラとして自然に隠蔽します
 また、ViewModelはViewをインターフェースすら
意識する必要がなくなり、よりレベルの高い疎結合
が実現されます。
データバインディング
View
ViewModel
InteractionMessage
(補足)InteractionMessage
 データバインディング機構は、Viewと下位レイヤの
Interactionに有効ですが、Viewがバインドする下
位レイヤにバインドするデータがあることが前提で
す。
 そのため、Viewでのエラーダイアログボックスの表
示や、画面遷移など、揮発性の現象に対しては不自
然な実装を強いられます。
 Viewの下位レイヤからの揮発性のアクションを実現
するための仕組みがInteractionMessageです。
(補足)InteractionMessage
 しかし現在、.NET Framework4/Silverlight4にお
いて、標準でInteractionMessageは導入されていま
せん。
 Pattern & Practice Prismにおいて
InteractionMessageは導入されています。P & Pに
採用されている以上、いずれは標準ライブラリでの
採用が見込まれるでしょう
 参考):MVVM勉強会資料
 http://ugaya40.net/wpf/mvvm-study-
resource.html
MVVMパターン – まとめ
 MVVMパターンは、MVC系の理念を持つパターンで
あり、WPF/Silverlightの基盤特性に最も適した
MVC系亜種PresentationModelパターンを、さら
にWPF/Silverlightの基盤機能に合わせて特化させ
たもの。
 PresentationModelパターンと比べるとMVVMパ
ターンは、WPF/Silverlight/.NETの基盤技術をフル
活用する事で、開発者がパターンを破壊するコード
を記述する事を防ぎやすくしている
MVVM Future
 コードビハインドが初めから無いMVVMテンプレー
トのVisualStudioへの導入。
 Expression Blendビヘイビア・トリガー・アクショ
ンの、標準ライブラリへの導入
 Viewに宣言的に機能を追加できる
 PrismのInteraction/InteractionMessageTriggerの
標準ライブラリへの導入
参考資料
 各UIパターン概要
 matarillo.com UIパターン
http://matarillo.com/general/uipatterns.php
 PMパターンとMVVMパターンの関連
 MSDN マガジン February 2009
Model-View-ViewModel
デザインパターンによる WPF アプリケーション
http://msdn.microsoft.com/jajp/magazine/dd419663.aspx
 THE CODE PROJECT Presentation Model (MVVM) Good
Practices
http://www.codeproject.com/KB/silverlight/pmgoodpractic
es.aspx
 MARTIN FOWLER Presentation Model
http://martinfowler.com/eaaDev/PresentationModel.html

Download Report