MVVMパターンとは?(public)

+59

No comments posted yet

Comments

Slide 1

MVVMパターンとは? WPF/Silverlightの特徴と一般的な設計原則から導出するMVVM(Model/View/ViewModel)パターン

Slide 2

WPF/Silverlightの特徴と、 一般的な設計原則から WPF/Silverlightのための設計パターンである MVVMパターンを導出して、 MVVMパターンはなんら特別なパターンではないという事を理解して頂きます。 また、インフラの必要性についても話します。 アジェンダ

Slide 3

WPF/Silverlightの考慮すべき特徴の紹介 見た目と機能の分離 WPF/Silverlightアプリの設計定石を考える(1) 一般的な設計原則から WPF/Silverlightアプリの設計定石を考える(2) WPF/Silverlightの特徴から、そしてMVVMパターンへ MVVMパターンのはまり所 よくある誤解 まとめ アジェンダ

Slide 4

WPF/Silverlightの 考慮すべき特徴の紹介 ControlTemplate VisualStateManager 双方向データバインド DataTemplate

Slide 5

同じコントロールも外観をXAMLだけで別の外見に。 外見の変化はカスタムコントロールを作る動機ではなくなった。 コントロールの機能と外観の分離(1) ControlTemplate <TreeView> <ListBox> 画像貼りミス じゃないんですよ!

Slide 6

コントロールに状態に応じた外観を定義する事が可能になった。(状態間にアニメーションの定義も可能/状態を追加する事も可能) 外観に関わるコードはこうやってほぼ全てXAMLに委譲できる。 コントロールの機能と外観の分離(2) VisualStateManager

Slide 7

WPF/Silverlightのデータバインディングは双方向のデータバインドに対応している データバインド指向(1) 双方向データバインド

Slide 8

コレクションコントロール(ListBox/TreeView)などには最強の武器がある。 データバインド指向(2) DataTemplate

Slide 9

WPF/Silverlightでは見た目に関する定義をほとんどXAMLに委譲できるようになっている。 データバインドが見た目と機能の分離をさらに促進する。 データバインドに頼らないで作ろうとすると動作に制約がつく。 たとえばC#/VBコードから構築されたDataTemplateではTemplateのすべての機能を使用する事ができない旨がMSDNに明記されている http://msdn.microsoft.com/ja-jp/library/ms602715.aspx WPF/Silverlightの考慮すべき特徴 まとめ

Slide 10

WPF/Silverlightの 設計定石を考える(1) 一般的な設計原則から レガシーなイベントドリブンコードの問題点 相互依存 ざっくりとした一般的なGUI責務分割型設計

Slide 11

イベントハンドラに全ての処理を書くと、イベントの発生順序とビジネスドメイン(アプリ本来の問題領域)の処理が強く結合してしまいやすい。 レガシーなイベントドリブン イベントの発生順序と処理の依存

Slide 12

アプリ本来の処理シーケンスと、見た目のコードの混在を片づけるには、そりゃあ責務を分離すれば良いんです。 しかし気を付けなければならない事があります。 相互依存です。 レガシーなイベントドリブン 対策

Slide 13

相互依存とは 分割された責務が、互いが互いに依存する事。 相互依存 相互依存が引き起こす事

Slide 14

互いが互いに依存する事で単一責任の原則に反しやすくなる。 相互依存 相互依存が引き起こす事

Slide 15

インターフェースによるアプローチ 相手がインターフェースを実装している事だけを知っていれば良い。 OOPでの疎結合の基本。 相互依存 相互依存の排除(1) – シンプルなinterface

Slide 16

イベントでのObserverパターンによるアプローチ Observeとは監視するという意味。 イベント受信側について、イベント発行側が全く知る必要がない。 相互依存 OOPでの相互依存の排除(2) - Observer

Slide 17

責務間の関連が深い(通信相手の存在が前提)場合がシンプルなinterfacceの方が良い。 記録処理クラスと、記録の実体(ファイル・DB)クラスの通信 いわゆるリポジトリパターン 責務間に関連が無い場合はイベントObserverによるアプローチが良い 完全に責務に関連がない場合、通信相手の存在を前提としたシンプルなinterfaeよりObserverの方が優秀。 相互依存 シンプルなinterface vs Observer

Slide 18

ここまでを踏まえて、GUIアプリをざっくり分けてみます。 まずはざっくり分けてみよう 外観 ビジネスドメイン (アプリの機能) 呼出 ビジネスドメインから外観への通信はイベントの方が望ましい イベント通知

Slide 19

ここまでを踏まえて、GUIアプリをざっくり分けてみます。 まずはざっくり分けてみよう 外観 View ビジネスドメイン Model 呼出 イベント監視 イベント通知

Slide 20

実はこれがMVCに代表されるUIパターンの共通理念であり、基本的な形。 まずはざっくり分けてみよう View Model 呼出 イベント監視 イベント通知

Slide 21

全てのUIパターンの正しい理解のためには、この形を理解する事が基本です。あとでも出てくるので覚えておいてください。 まとめ View Model 呼出 イベント監視 イベント通知

Slide 22

WPF/Silverlightの 設計定石を考える(2) WPF/Silverlightの特徴から、 そしてMVVMパターンへ コレクションコントロールの罠 イベントの発生順序とコントロールの状態の複雑化 別途状態ストアを持とう! MVVMパターン

Slide 23

コレクションコントロールには罠がある。 ListBox/ListView コレクションコントロールの罠

Slide 24

コレクションコントロールには罠がある。 TreeView コレクションコントロールの罠 展開するまで やはり子のインスタンスが無い!

Slide 25

コレクションコントロールの罠

Slide 26

DataTemplate内の別のコントロールの情報をとりにくい VisualTreeHelperとかいう静的クラスの、 自分の子の数を習得するだけのメソッドと インデックスで対象の子コントロールを取得してくるだけのメソッド でしか、DataTemplate内のコントロールは触る事ができない。。。有り得ない。。。 コレクションコントロールの罠

Slide 27

ではどうするか → データバインドで全て解決 コレクションコントロールの罠 各項目に対応するような 表示用のデータバインド用オブジェクトがあれば全てデータバインドで解決できる (チェック状態などもboolとして持つ) むしろ他のアプローチじゃ解決できない!

Slide 28

WPF/Silverlightではコントロールはとことんデータバインド前提で作られている。 コレクションコントロール以外でも、レイアウト関連プロパティなどでは、イベントの発生状況によってプロパティの値が信用できない。 WinForms/ASP.NETまではむしろデータバインドはおまけ機能の印象が強かった。 WPF/Silverlightではデータバインドこそが本流。使わないと制約だらけ。 WPF/Silverlightコントロールの 特徴

Slide 29

コントロールの状態(プロパティ)を、ビジネスドメイン呼び出しのための状態判断に信用しない方がよいのが、WPF/Silverlight。 コントロールの状態は、レイアウトシステムとの連携やコントロールの内部実装で使用する事になる。 だから・・・・ WPF/Silverlightコントロールの 特徴

Slide 30

コレクションコントロール以外のものも含めて、画面のレンダリングに必要な動的に変化する情報を保存する責務を新たに設ける。 画面のための状態ストアを持とう! バインド用オブジェクト ● ● ● ● ● ● ● ● ● テキスト:1992 テキスト:1993 選択されているかどうか 選択されているかどうか バインド!

Slide 31

画面を描画するための状態ストアを別途持ってしまおう! 画面のための状態ストアを持とう! 外観 画面 XAML 画面を レンダリングする ための状態ストア Data Binding

Slide 32

つまりこれが・・ 画面のための状態ストアを持とう! 外観 ビジネス ドメイン (アプリの機能) 呼出 イベント

Slide 33

外観 画面のための状態ストアを持とう! 画面 ビジネス ドメイン (アプリの機能) 画面を レンダリングする ための情報 呼出 イベント Data Binding

Slide 34

View : UIの外観と構造を定義 ViewModel : Viewをレンダリングするための情報 Model : アプリ本来の問題領域に対するコード 画面のための状態ストアを持とう! 画面 View ビジネス ドメイン Model レンダリング情報 ViewModel 呼出 イベント Data Binding

Slide 35

この形の事をMVVMパターンと言います。見ての通り、なんら難しいパターンでも、特別なパターンでもないのです。 MVVM(Model/View/ViewModel)パターン View Model ViewModel 依存 イベント Data Binding

Slide 36

MVVMパターンのはまり所 よく勘違いで実装されるポイントを説明します

Slide 37

MVVMパターンはMVC系パターンの一種です。 MVC系パターンの共通の目的として、ドメインロジックとプレゼンテーションロジックの分離があげられます。 MVC系がより強く叫ばれるのはWeb系ですので、Web系開発者の原則がそのまま適用され、リッチクライアントでは不適切な設計がされる事が多々あります。 そのいくつかをご紹介します。 MVVM(Model/View/ViewModel)パターン はなぜよく勘違いされるのか

Slide 38

Web開発経験者の中には3層っぽいというだけで、こんな形にしちゃう人がいます。 3層? 画面 データ アクセス ビジネスロジック プレゼンとドメインの分離ができていません。 真ん中は実際は画面制御もすることになりますね。 MVC系のそもそもの目的はどこに? ビジネスロジックもデータアクセスもModelの中が適切

Slide 39

クライアント側はViewModelからという考え方。 サーバと通信するアプリの Modelは・・? View Model (サーバ) ViewModel 通信ロジックとか、ユーザーIDとか管理するのは ViewModelなの?プレゼンとドメインが(ry サーバとクライアントは違う目的を持つ違うアプリです。 Modelはほぼ必ずクライアント側にもある層ですよ。

Slide 40

リッチクライアントはステートフル(状態を持つ)ものでしょ?。Webみたいにリクエスト毎がオブジェクトのライブサイクルじゃないです。 ステートレス?いいえ、ステートフル View Model ViewModel

Slide 41

ステートフルなModelがただのデータの入れ物という考え。やはりWebからの人が(ry Modelはただのデータの入れ物? View Model (サーバ) ViewModel 入れ物にデータを入れるのはどこの層なのよ?ViewModel? やはりビジネスとプレゼンの分離が(ry リッチクライアントのModelは操作を持ちますし、自身の状態を変化させたり、別のオブジェクトに変化を通知しますよ。

Slide 42

まとめ

Slide 43

まとめ MVVMパターン 外観 画面 View ビジネス ドメイン (アプリの機能) Model 画面を レンダリングする ための情報 ViewModel 呼出 イベント Data Binding 特別なパターンどころか、 むしろWPF/SLにとって一択ってくらい普通のパターン

Slide 44

まとめ MVVMパターン 責務 View:UIの外観と構造を定義 ViewModel :UIレンダリングのためのデータストア Model : アプリ本来の問題領域を表すコード 責務間の通信 View⇔ViewModel : 極力双方向データバインディングで。インフラの導入具合によっては全てデータバインディングに統一する事も可能。 ViewModel⇔Model : イベントとメソッド呼び出し

Slide 45

まとめ MVVMパターン 各種MVVMインフラが提供する機能は、WPF/SilverlightでMVVMパターンの持つ思想のメリットをより引き出したり、面倒な考慮事項を失くすためのもの。DelegateCommand使うからMVVMとか、コードビハインド無いからMVVMとか勘違い。 スキルに自信がないからこそMVVMインフラを使う。

Slide 46

まとめ 今後の学習 - 概念に踏み込む MVVMで良く聞く具体的な実装要素(DelegateCommandとか)のうち、何を使えばどういうメリットがあり、使わなければどんなメリットが損なわれるかを把握する事で実務での導入をしやすくする。 @IT MVVMパターンの常識 「M」「V」「VM」の役割とは? http://www.atmarkit.co.jp/fdotnet/chushin/greatblogentry_02/greatblogentry_02_01.html

Slide 47

まとめ 今後の学習 - 概念に踏み込む MVC/MVP/PMなどの、別のUIパターンとの違いを学ぶ。 the sea of fertility MVVMパターンとイベント駆動開発、そしてMVC/MVP/PMパターンとの関係 - 何故MVVMなのか http://ugaya40.net/wpf/mvvm-mvc-mvp-pm-eventdriven.html

Slide 48

まとめ 今後の学習 – 採用環境ごとに何をしるべきか .NET/Silverlight標準、MVVM Light Toolkit/Prism/Livetなどを採用した場合の何をどこまで学べば良いかのガイドライン。  the sea of fertility MVVMパターン学習のファーストステップ - 何をどこまで勉強するか http://ugaya40.net/mvvm/mvvm-first.html

Slide 49

ご清聴 ありがとうございました

Summary: WPF/SilverlightにおけるMVVMパターンの啓蒙押し量です。資料の直接の商用理由以外で、啓蒙目的に限りご自由にお使いください。 MVVMパターン的な実装は他のプラットフォームでは選択肢の一つですが、WPF/Silverlightでは唯一の選択肢です。

Tags: wpf silverlight mvvm

URL: